What engine you are testing against
The document is parsed with the browser XML parser and the expression is run through the browser XPath implementation. That means XPath 1.0, which is what every browser ships and what a great deal of tooling still assumes. Version 2.0 and 3.1 features are simply not available: no for expressions, no let bindings, no sequence types, no regular expression functions beyond what 1.0 provides.
In practice XPath 1.0 covers most of what people actually write. Axes, predicates, position, contains, starts-with, substring, count, and the node tests all work. What you notice missing tends to be string manipulation, since 1.0 has no ends-with and no matches, and those absences are the usual reason an expression written against a 2.0 processor fails here.
Because this is the browser implementation, an expression that works here will work in a browser script using the same evaluation call. If your XPath is destined for a Java, Python, or .NET processor, most of it will carry over, but the version those libraries implement may be newer and more permissive than what you tested against.
- XPath 1.0 only, because that is what browsers implement
- Axes, predicates, and the common string and node functions all work
- No ends-with, no matches, and no XPath 2.0 or 3.1 constructs
XML mode, and what that implies for HTML
The document is parsed strictly as XML. That has a direct consequence: the input has to be well-formed. Every tag must be closed, attributes must be quoted, ampersands must be escaped, and tag names are case sensitive. If any of that is wrong, you get a parse error message instead of a result, which is more useful than a silently truncated document.
It also means this is not an HTML tester. Real-world HTML relies on the browser error-correcting parser to close unclosed tags and tolerate unquoted attributes, and none of that leniency applies here. Pasting a page source scraped from the web will usually fail to parse. Convert it to well-formed XHTML first, or test HTML selectors with a different tool.
Namespaces are the other significant gap. The evaluation runs without a namespace resolver, so an expression cannot use a prefix to select elements in a namespace. Documents with a default namespace, which includes most real SVG, RSS, and SOAP, need the local-name workaround: match on the local name in a predicate rather than naming the element directly.
Reading the results
XPath 1.0 returns one of four kinds of value and the tester handles all of them. A node set is listed as individual results with a count above them. A string expression, such as one wrapped in string-of or concat, shows the string value. A number, from count or sum or a numeric operation, shows the number. A boolean, from a comparison or the boolean function, shows true or false.
Within a node set, each result is labeled by kind and serialized appropriately. An element is shown as its full markup including children, so you can see exactly what was selected. An attribute is shown as its name and value. A text node shows its trimmed content and a comment shows its comment syntax. That labeling matters, because selecting an attribute when you meant its element is one of the easiest XPath mistakes to make and the label catches it immediately.
The node count sits above the results, and an empty node set says so explicitly rather than showing nothing. Very large result sets are truncated after several thousand nodes, which is far past the point where reading them individually stops being useful.
- Node sets, strings, numbers, and booleans are each displayed appropriately
- Each node is labeled by kind and serialized: full markup for elements, name and value for attributes
- An empty node set is stated explicitly, and very large sets are truncated