XPath Tester

The scraping code you inherited has one line that does all the real work: //div[@class='result']/table/tr/td[3]. Nobody left a comment. The API you're integrating against returns XML, not JSON, and the integration guide says "the value is at /response/shipment[status='delayed']/eta" with no further explanation. A vendor's product feed arrives as 40 megabytes of nested elements and you need exactly three of them. All of these are XPath moments, and all of them share the same problem: you cannot write an XPath expression down confidently without running it against real data.

XPath is older than most of the people using it — the W3C published version 1.0 in November 1999, back when XML was going to be the format for everything. The prediction was wrong in general and right in specific: JSON won the APIs, but XML never left the places it had already conquered. Enterprise config files, SOAP endpoints, office document formats, RSS and Atom feeds, SVG, sitemaps, DocBook, HL7 medical records, the publishing industry's entire backbone. If you touch any of those, you touch XPath.

This tester is the missing REPL. Paste or load your XML, type the expression, and see exactly which nodes match — highlighted, counted, and drillable — or see the scalar result if your expression computes one. It runs on the XPath engine already installed in your browser, so the behavior you verify here is the behavior your production code will get.

The page is two panels and an input bar, deliberately spare. The document panel takes XML three ways: pasted text, a loaded file, or one of the built-in samples (an orders file, an XHTML fragment with namespaces, an Atom feed). The expression bar evaluates as you type — every keystroke, no run button needed — and the results panel reacts in three shapes depending on what your expression returns.

A node-set result highlights the matched nodes inside the document view and lists them underneath with full paths, so //order[@status='shipped'] doesn't just say "2 nodes" but shows you which two. A scalar result — count(//order), sum(//total), a string pulled by substring() — displays as a value. A boolean, typically the output of a comparison used inside a larger predicate but perfectly testable alone, shows as true or false. Getting all three shapes back matters more than it sounds: half of debugging an XPath is discovering that what you thought was a node-set is actually a number.

When an expression fails, the error message comes straight from the browser engine with its position, which is worth its weight: a malformed predicate like //lineqty > fails with a syntax complaint pointing at the spot, instead of the silent nothing that a naive regex-based tester would hand you. There's also a cheat sheet of axes and functions docked beside the editor, and a namespace-aware mode for documents whose elements carry prefixes. It's the same engine concept as our [JSON Path Tester, aimed at the XML side of the fence.

1. 1

   Put a document in

   Paste XML, drop a file, or click a sample. The document parses immediately — if it isn't well-formed XML, you hear about that first, before XPath enters the picture.

2. 2

   Type the expression

   Evaluation is live. As you type, the match count updates; finish the expression and the highlighting settles on whatever it selects.

3. 3

   Inspect the matches

   Click any result in the list to jump to it in the document view, where it stays highlighted with its full path shown. Matched nodes are numbered in document order.

4. 4

   Refine or export

   Tighten the predicate, add a position filter, switch the context node if you're working relative to a section — then copy the verified expression into your scraper, stylesheet, or test.

A habit worth forming: start with the broadest expression that returns anything — //order — then narrow one predicate at a time until the match count is what your business logic says it should be. The tester's instant feedback makes that a thirty-second loop. Writing the final expression in one shot, by contrast, is how //div[2]/span[contains(text(),'Total')] ends up selecting a currency label on Tuesdays and nothing at all on weekends.

Every location path is a sequence of steps, and every step has three parts: an axis, a node test, and any number of predicates. Written out longhand it's child::order[@status='shipped'][2] — the child axis, the order node test, two predicates. Abbreviated, which is how everyone actually writes it, the child axis vanishes (order), attributes get @ (@id), parent gets .., self gets ., and descendant-or-self gets //. The abbreviations are why XPath looks like file paths with superpowers.

The node test is the coarse filter — a name like order, a wildcard like * for any element, or node() for any node at all including text and comments. Predicates are the fine filter, evaluated as boolean expressions per candidate node, left to right: [@status='shipped'] keeps matching elements, [2] keeps the second, [@status='shipped'][2] means "of the shipped ones, the second" — note that order, because [2][@status='shipped'] means "of the second one, keep it if shipped," a subtly different and usually accidental question. Stacking predicates is the feature and the trap in one syntax.

Predicates can use the full expression language, which is where XPath stops being a path language and starts being a small functional one. Arithmetic (+, -, *, div, mod — division is div because / is taken), comparisons (=, !=, <, <=, >, >=), boolean glue (and, or, not()), and the core function library: position() and last() for ordering, count() and sum() over node-sets, contains() and starts-with() and substring() and normalize-space() and translate() for text surgery, concat() for assembly, string-length() for validation. The node-test wildcards and this function set together are 90% of production XPath.

// Production XPath, annotated:

//line[@qty > 10]/@sku
  → descendant-or-self of root → any 'line' element
    with qty attribute > 10 → its sku attribute

//order[customer = 'Meridian Foods' and total > 500]/@id
  → orders for one customer whose total clears 500 → their ids

//line[not(@qty)]
  → every line element missing a qty attribute entirely — data QA

Axes are the directions a step can travel. Child is the default and covers most walking; attribute covers @; the rest exist for the moments a path needs to move sideways or upward, which is exactly what CSS selectors historically couldn't do. There are thirteen in XPath 1.0, and nobody uses them uniformly — so here they are in rough order of real-world frequency.

The parent and sibling axes deserve a small celebration, because they're the reason scrapers reach for XPath over CSS at all: from a price cell you can climb to its row, and from the row to the header that names the column. When the layout moves, the relationship survives, and your expression survives with it. The following and preceding axes are the ones to treat with care — they traverse the whole document outside your subtree, so on a large file they are the slowest steps available and occasionally a correctness hazard, since 'preceding' includes nodes the human eye groups with other sections.

Here is the tester's built-in sample document, abbreviated — three orders, five line items, one shipped-status mix. Every result below was evaluated against this exact XML, and you can reproduce each one in the tester with one click.

<orders>
  <order id="A-1001" status="shipped">
    <customer>Meridian Foods</customer>
    <lines>
      <line sku="SKU-91" qty="12" unit="41.50"/>
      <line sku="SKU-33" qty="4" unit="129.00"/>
    </lines>
    <total>1014.00</total>
  </order>
  <order id="A-1002" status="open">
    <customer>Halcyon Print</customer>
    <lines>
      <line sku="SKU-91" qty="2" unit="41.50"/>
    </lines>
    <total>83.00</total>
  </order>
  <order id="A-1003" status="shipped">
    <customer>Meridian Foods</customer>
    <lines>
      <line sku="SKU-17" qty="30" unit="8.25"/>
    </lines>
    <total>247.50</total>
  </order>
</orders>

The last example is the one to memorize, because case-sensitive contains() bites everyone once. The fold-the-case-with-translate trick predates Google and will outlive us all, at least until browsers decide to implement an XPath version newer than 1.0 — a decision they have now declined for over two decades.

• Namespaces, the big one. If the root declares xmlns="http://www.w3.org/1999/xhtml" (or any default namespace), every unprefixed element name in your XPath matches nothing, because in XPath 1.0 an unprefixed name matches only elements in no namespace. The fix is a namespace resolver mapping a prefix of your choice to that URI, then x:html/x:body. The tester's namespace mode lists declared namespaces and wires the resolver for you.
• Text nodes versus string values. /order/customer returns the customer element; /order/customer/text() returns its text node. For comparisons it rarely matters — string() of an element includes descendant text — but node-identity and count() care a lot, and text() breaks silently when a value is split across multiple text nodes by markup.
• The double-slash performance tax. // scans the entire subtree from the document root every time it appears. On a 40 MB product feed, //sku inside a loop is the difference between seconds and a coffee break. Anchor your paths (orders/order/lines) whenever the structure is stable enough to describe.
• Position is per-axis, per-step. line[2] means the second line child among its siblings, not the second match document-wide. To get the second match overall, filter the outer step: (//line)[2] — parentheses first, then the position predicate. Those parentheses are load-bearing.
• Numbers are IEEE double precision. Attribute comparisons like @qty > 10 do exact floating-point math — quantities stored as 41.50 are fine, but penny arithmetic on decimal values can wobble in the usual 0.1-plus-0.2 way. Don't build a billing engine out of XPath predicates.
• Comments are nodes. The node() wildcard and the comment() node test can both select XML comments, and a naive text extraction can accidentally include a commented-out block that a human "deleted" fifteen years ago. Ask for element names explicitly when it matters.
• CDATA is just text. What the document author wrapped in <![CDATA[...]]> arrives as an ordinary text node as far as XPath is concerned — invisible in the syntax, occasionally surprising when a "different-looking" value compares equal to a plain-text one.

Integration engineers, mostly — people whose week is a parade of other people's formats. The freight system speaks XML. The publisher's CMS speaks XML. The government data portal absolutely speaks XML, frequently XML from 2003 with a schema PDF to match. When the requirement is "pull fields X, Y, and Z out of this payload and map them into our system," the expression work happens here first, against a real sample, until the match count is boring.

Scrapers form the second camp, split between XPath and CSS partisans in a way that generates entertaining team arguments. XPath earns its following for the reasons above — upward traversal, attribute selection, functions, and compound predicates that CSS only answers with the newer :has() and attribute operators. Test automation leans the same way: Selenium and Playwright both accept XPath locators, and a locator verified in a tester before it's committed is a locator that doesn't fail at 2 a.m. in CI.

The third camp is quieter: XSLT maintainers (stylesheets are XPath with a rendering engine attached), technical writers in DocBook territory, anyone doing batch transformations with tools like xsltproc, and data people sanity-checking sitemap XML before search-console work. Their expressions are fewer and stranger, and they appreciate a namespace resolver more than anyone.

For scraping HTML, the eternal question: XPath or CSS? Both work. They differ in ways that matter once you leave the happy path.

The practical split we see: CSS when the path is short, downward, and structural — article > h2, #results .row — because it reads cleanly and engines optimize it hard. XPath the moment you need text matching, a climb to a parent, attribute values as the result, or a compound condition across two attributes. The tester here plus the browser console's $x() make it cheap to prototype in XPath and only commit what survives contact with the page. And when the data is JSON rather than markup, neither applies — that's JSON Path Tester territory.

There is no XPath implementation on this page to trust, because the browser brought one. The tester calls document.evaluate — the standard DOM API, present in every modern browser since the mid-2000s — hands it your expression and your document, and renders whatever XPathResult comes back. What you test is not a reimplementation that approximates the spec; it is the same engine your scraper's browser session, your XSLT processor's cousin, and your production code will exercise. When a result surprises you here, it would surprise you in production identically.

The document you paste never crosses the network. Parsing, evaluation, highlighting: all local, all in-tab, gone when the tab closes. That's not just a privacy posture — it's what makes an offline XPath REPL possible on a train or inside a locked-down environment. Load the page once and the network panel stays quiet thereafter; verify it yourself if you like.

The usual workflow around here: format and validate the XML first with XML Formatter & Validator, prototype the expression here, then either convert the result set with XML to JSON for downstream tooling or hand the verified expression to your scraper. If your selector problem lives in JSON instead, JSON Path Tester is the mirror-image tool. And when the extraction job is really a reformatting job, Regex Tester covers the flat-text cases XPath was never meant to touch.