XPath tester

This XPath tester runs XPath 1.0, and says so before you wonder

Every browser ships an XPath engine. It is reachable as document.evaluate, it is the same engine that powers a Selenium or Playwright locator, and it implements XPath 1.0 — the 1999 recommendation, and nothing after it. That is the engine this page hands your expression to. No XPath library is downloaded, because there is nothing to download: the implementation is already sitting in the tab you are reading this in.

The version matters more than it sounds like it should. Several well-known online testers run XPath 2.0 or 3.1 on a server, usually Saxon, and an expression that works there can fail in the place you actually needed it — a browser, a scraper built on lxml in its default mode, or an Android layout inspector. Going the other way is worse: an expression written against 1.0 is silently accepted by a 2.0 engine and can mean something slightly different. So the number is printed next to the expression field rather than buried in a footnote, and when your text contains a construct that only exists in a later version, the page names the construct instead of leaving you with the browser's wording. There is no matches() in XPath 1.0, no upper-case(), no if … then … else, no for $x in, no sequences, and no except. There is translate(), substring-before(), contains(), count() and a predicate, and that is a surprisingly long way.

The namespace resolver is the whole job, not an extra

Most XML that anyone brings to an XPath tester carries a namespace. A SOAP envelope, an Atom feed, an XLIFF file, a Maven POM, a sitemap, an SVG — every one of them declares xmlns on its root, and every element inside is therefore in that namespace. XPath 1.0 has no concept of a default element namespace, so the obvious expression //book/title asks for elements in no namespace, matches zero nodes, and reports no error whatsoever. That silence is the single most common reason people conclude their expression is wrong when it is their binding that is missing.

The fix is a resolver, and here it is a visible field rather than a hidden behavior. Write one binding per line as prefix = uri, then use that prefix in the expression: b = http://example.com/books makes //b:book/b:title work. The prefix is entirely yours to pick. It does not have to be the prefix the document happens to spell, because XML matches on the namespace URI and the prefix in the source is just a local nickname. A button fills the field with the namespaces the document actually declares, so you can start from the truth and edit from there. If the expression uses a prefix you have not bound, the result is nothing at all, and the page says which prefix — rather than throwing a browser error that names no prefix and no position.

Four result types, because XPath returns four things

An XPath 1.0 expression evaluates to a node-set, a string, a number or a boolean, and which one you get is decided by the expression, not by a setting. //book is a node-set, string(//title) is a string, count(//book) is a number and //book/@id = "b1" is a boolean. This page asks the engine for whichever type the expression produces and prints it, so a tool that only ever showed matched nodes cannot mislead you about what your expression really returns. For a node-set it also shows what XPath itself makes of that set as a string, a number and a boolean — the first node's text, that text read as a number, and whether the set is non-empty. Those three conversions are the reason //price > 10 is true as soon as one price exceeds ten, and seeing them written out tends to end the argument faster than reading the specification does.

Errors: the document has a position, the expression does not

A malformed document is caught before anything is evaluated, and the browser's own XML parser reports where it stopped — a real line and column, worded identically in Chrome and Safari, shown here exactly as given. Fixing an unbalanced tag is a job for the XML formatter and validator, which validates first and refuses to transform a broken tree.

A broken expression is different, and the difference is worth stating plainly. Chrome throws a syntax error whose message repeats your whole expression and carries no offset. Safari throws one whose message is “The string did not match the expected pattern” and whose line and column properties were measured to be identical for every expression tested, because they describe this page's own JavaScript rather than your text. Neither browser tells you where the expression broke. So this page does not pretend to: it says the browser gave no position, quotes the engine word for word, and separately runs its own bracket, parenthesis and quote balance check whose position is labeled as a measurement made here. An invented line number is worse than none, because the next person believes it.

What this page does not do

It does not generate an expression for you. Pointing at a node and asking for a path is a genuinely different tool with a different main surface — a rendered, clickable tree — and it would belong on its own address rather than as a mode on this one. It also does not run XPath 2.0 or 3.1, which would mean shipping a full engine and reviewing its license first; when that happens it will be its own page with its own version printed on it, not a checkbox here. For patterns over plain text rather than paths over a tree, the regex tester answers the neighboring question, and for the other structured formats there is a JSON formatter and an HTML formatter and minifier.

Parsing and evaluation happen in this browser tab. The XML someone brings to an XPath tester is usually an API response, a build configuration or a customer export, so nothing is placed in the address bar, in browser storage, or in a shareable link — which also means there is no link to share, deliberately. The verification guide explains how to confirm that boundary yourself with the network panel open.