Master XPath: Interactive Guide to XML Navigation

XPath continues to have a strange reputation in tech: for some, it is an indispensable gem; for others, a relic of the XML world. Both views fall short. XPath is not “old” by definition nor “modern” by marketing: it is a specialized language for navigating and querying hierarchical structures, and it remains highly relevant when working with XML, XSLT, automation, documents with namespaces, SVG, sitemaps, or APIs and tools that still depend on the XML ecosystem. Furthermore, in the current web platform, native APIs such as Document.evaluate() and XPathResult still exist, widely available in browsers for years.

The important thing in 2026 is not to repeat that XPath “is used to select nodes”, but to understand where it contributes more than CSS or simple searches, and where it is better not to use it. In modern automation, for example, Selenium still supports xpath as an official locator strategy, while Playwright supports it but recommends prioritizing more resilient locators like role, text, or test id; additionally, Playwright makes it clear that XPath does not pierce shadow roots. That combination summarizes the current moment very well: XPath continues to be useful, but it is no longer used with the same philosophy in all stacks.

What is XPath, explained without fluff

XPath stands for XML Path Language. The W3C itself defines it as an expression language that allows processing values conforming to the XDM data model and whose most distinctive feature is the path expression, that is, a form of hierarchical addressing over nodes of an XML tree. XPath 3.1 is not limited to “simple XML trees”: the model also includes atomic values, sequences, function items, and structures added in 3.1 like maps and arrays.

Practically speaking: XPath allows you to move through a document as if it were a tree and answer questions of the type “give me all the products with a price greater than X”, “find me the second node of this type”, “go up to the parent”, “look for a preceding sibling”, “filter by attribute”, “work with namespaces”, or “evaluate a textual condition”. That is where XPath usually gains power over simpler approaches. MDN, in fact, maintains a specific guide comparing CSS Selectors and XPath to help choose the right tool depending on the type of query.

Why XPath remains important in 2026

The first reason is simple: the standard is still valid. There is no Recommendation subsequent to XPath 3.1 in the W3C history, so it remains the current normative reference point. Furthermore, XPath does not live isolated: it is part of the XQuery/XDM ecosystem and remains connected to the more deeply established XML transformation and querying world.

The second reason is that browsers continue to expose XPath. MDN documents Document.evaluate() as an API widely available and usable on both HTML and XML documents. At the same time, the DOM Standard clarifies an important nuance: the legacy APIs from DOM Level 3 XPath to evaluate expressions are XPath 1.0 APIs, widely implemented, but which have not received active maintenance. That detail matters a lot because it avoids confusing the general XPath 3.1 standard with what the browser exposes through the DOM.

The third reason is that XML has not disappeared. The Sitemaps protocol continues to be defined in XML format; SVG continues to be an XML-based markup language; and the web platform itself continues to include DOMParser and XMLSerializer to parse and serialize XML in the browser. We are not in 2008, but neither are we in a world where XML has ceased to exist.

The fourth reason is the tooling. Java continues to include javax.xml.xpath in its standard stack, with APIs to evaluate expressions and work with typed results; and Python maintains XPath support in xml.etree.ElementTree, although its own documentation makes it clear that this support is limited and only covers an abbreviated subset, not a full XPath engine. That means XPath is very much alive, but also that not all implementations offer the same depth.

The most common mistake: thinking that XPath is only used to “find tags”

That approach greatly reduces the language. XPath is not simply an alternative to getElementsByTagName(). Its real value appears when you need structural relationships and expressive filters: parents, ancestors, siblings, positions, attributes, textual content, functions, and namespaces. MDN lists XPath axes and functions, and its comparison with CSS shows precisely that XPath remains interesting when you need richer structural navigation.

Correct mental model: think in a tree, not in text

XPath works best when you stop seeing XML as “text with tags” and see it as a tree of nodes. The Python documentation on ElementTree explains it very well: XML is an inherently hierarchical format and the natural way to represent it is a tree. Once you have that model in your head, expressions like //book, ../title, @id, or [2] stop looking like weird syntax and become navigation between tree relations.

Interactive mini laboratory: understand XPath with a real XML

Let's use a simple XML:

<library>
  <book id="b1" category="testing">
    <title>Playwright in Action</title>
    <author>Nestor Alonso</author>
    <price>39.99</price>
  </book>
  <book id="b2" category="automation">
    <title>Cypress from Zero to Hero</title>
    <author>Ana Ruiz</author>
    <price>29.99</price>
  </book>
  <book id="b3" category="xml">
    <title>Mastering XPath</title>
    <author>Carlos Vega</author>
    <price>49.99</price>
  </book>
</library>

Now, think about these expressions.

1. All books

/library/book

This selects all the book nodes that are children of library. It is the most direct way to navigate by absolute path. The Python documentation shows this type of simple paths as part of the XPath subset supported by ElementTree, and MDN documents the same type of navigation in the browser's XPath evaluation APIs.

2. All titles, no matter where they are

//title

The // indicates descendant search at any level. In practice, it is very convenient, but it is also one of the most common causes of overly open and unmaintainable expressions when abused. Python documents // as selecting subelements at all levels under the current node.

3. The book with id="b2"

//book[@id='b2']

Here appears one of the most used patterns: filtering by attribute with a predicate. Python documents it within its supported syntax, and it is one of the reasons why XPath remains so expressive even in trimmed-down implementations.

4. The second book

/library/book[2]

Positional predicates are another classic advantage of XPath. ElementTree expressly documents that position can be an integer, last(), or a position relative to last().

5. The last book

/library/book[last()]

This type of query is very natural in XPath and much less elegant in other approaches. It is one of those small things that explain why XPath remains so appreciated in structural navigation.

6. The title of the XML category book

//book[@category='xml']/title

Here you combine filtering by attribute and descendant navigation. XPath becomes especially powerful when you chain simple tree steps instead of trying to build gigantic expressions. That way of thinking fits with the W3C's path expression idea.

7. All books whose title contains “XPath”

//book[contains(title, 'XPath')]

Functions like contains() turn XPath into something considerably more expressive than a rigid path. MDN maintains a reference of XPath functions and documents contains, starts-with, position, last, count, and other widely used ones.

8. The author sibling of the current title

//title/following-sibling::author

Here appears one of the superpowers of XPath: the axes. Navigating by siblings, parents, or ancestors is one of the areas where XPath usually brings much more than a simple CSS selector, although modern CSS has reduced some of that difference in some scenarios. MDN precisely compares XPath axes with CSS equivalents or approximations when they exist.

How to use XPath in JavaScript in the browser

In the browser, the key API is document.evaluate(xpathExpression, contextNode, namespaceResolver, resultType, result). MDN documents that this API evaluates XPath expressions over HTML or XML documents and returns an XPathResult. It also explains that namespaceResolver is used to resolve prefixes and that resultType controls whether you want a number, string, boolean, iterator, snapshot, or a single node.

Practical example:

const result = document.evaluate(
  "//book[@category='xml']/title",
  document,
  null,
  XPathResult.FIRST_ORDERED_NODE_TYPE,
  null
)

console.log(result.singleNodeValue?.textContent)

If you are going to evaluate the same expression many times, MDN also documents XPathEvaluator.createExpression(), which compiles the expression into a reusable XPathExpression. That makes sense when the query is repeated many times in the same flow.

Another important nuance is the result type. MDN explains that iterator results can be invalidated if the document changes, while snapshot results are not invalidated, although they may no longer reflect the current state of the document if it mutates. That difference matters a lot in debugging and in more dynamic scripts.

Namespaces: where XPath ceases to be trivial

Many developers say that “XPath is difficult” when in reality what is complicating their lives are the namespaces. In real XML, prefixes matter, and in the web platform Document.evaluate() needs a namespaceResolver when the expression uses prefixes. MDN documents this explicitly.

In Python, the ElementTree documentation recommends creating a dictionary of your own prefixes and using it in searches like find() or findall(). It also shows the less readable alternative of writing {namespace}tag directly. That advice is gold for any serious article on XPath, because namespaces are one of the most frequent reasons for “correct” queries that return nothing.

XPath in Python: useful, but with an important warning

The standard library xml.etree.ElementTree is very practical for many XML flows, but its own documentation clarifies that it offers limited support for XPath expressions and that a full XPath engine is beyond its scope. It supports a fairly useful subset—paths, //, filters by attribute, texts, positions, last(), and namespaces—but you should not assume full compatibility with XPath 3.1.

That is not an accidental weakness; it is a design decision. For normal parsing and selection tasks, that subset is usually enough. For complex queries, serious transformations, or scenarios with a lot of XPath semantics, it is advisable to use more specialized tooling.

XPath in Java: still part of the serious stack

Java continues to bring javax.xml.xpath as a standard API in java.xml. Oracle documents this package as an object-model-neutral API to evaluate XPath expressions and access the evaluation environment. It also documents interfaces and classes like XPath, XPathExpression, XPathEvaluationResult, and XPathNodes. That confirms that XPath is not an obsolete curiosity: it remains integrated into one of the most widely used enterprise ecosystems.

XPath in web automation: still alive, but with more discernment

In Selenium, XPath remains an official location strategy. The current Selenium documentation keeps xpath within its locator strategies, so it continues to be a normal part of E2E and WebDriver work.

But the modern nuance comes from tools like Playwright. Playwright supports CSS and XPath, automatically detects XPath when the selector starts with // or .., but its best practices recommend prioritizing role, text, and test id locators to achieve more resilient tests. Furthermore, Playwright warns that XPath does not traverse shadow roots. This combination is exactly what should be explained in 2026: XPath is not dead, but neither should it be your first indiscriminate choice for modern HTML UI testing.

XPath vs CSS in 2026: which to use and when

For modern HTML and interface testing, CSS or semantic locators are usually a better option when the intention is oriented towards the user or the visual structure. MDN maintains a guide comparing CSS and XPath precisely to help choose depending on the problem.

XPath usually wins when you need to go up the tree, navigate by axes like ancestors or siblings, apply complex positional filters, resolve namespaces, or work with XML documents where CSS simply is not the natural language of the problem. CSS usually wins when you work with HTML from modern frontends, especially if the goal is to write simpler selectors or ones aligned with more maintainable test strategies. Playwright reinforces that line by prioritizing role/text/test id over CSS or XPath in its recommendations.

Best practices for using XPath well

The first is not to abuse massive absolute paths like /html/body/div[3]/main/.... They work until the DOM changes slightly. XPath is more powerful when expressing structural intention, not when memorizing the exact shape of the tree. The Selenium documentation even includes common errors like InvalidSelectorException when XPath or CSS selectors are malformed.

The second is to control the context. In the browser, document.evaluate() receives a contextNode for a reason: many queries are clearer, faster, and safer if evaluated from a specific node and not from the entire document. MDN documents this directly in the method signature.

The third is to treat namespaces as part of the design, not as a rarity. When they appear, you must resolve them correctly in JavaScript or map them well in Python. A large part of the “XPath is not working” complaints are actually “my document has namespaces and I did not account for them”.

The fourth is to understand what implementation you have in front of you. Talking about XPath 3.1 as a W3C Recommendation is not the same as talking about the browser's DOM XPath 1.0 APIs, nor the limited ElementTree implementation in Python. In this topic, the context of the engine matters as much as the syntax.

Recommended internal links

Conclusion

XPath remains important in 2026 because it solves a problem that continues to exist: accurately navigating hierarchical structures. It remains completely valid as a W3C standard, it is still exposed by browsers, it continues to be integrated into Java, it remains present in Python although with partial support, and it is still highly relevant in automation and in real XML documents like sitemaps or SVG.

What has changed is the mature way of using it. In 2026, mastering XPath does not mean blindly shoving it everywhere; it means flawlessly knowing when it gives you a real advantage, when a CSS selector or a semantic locator is better, and how to properly handle contexts, predicates, positions, and namespaces. That is the fundamental difference between simply knowing syntax and truly mastering the tool. If you want to seamlessly bring your API and UI automation to the next level and design perfectly maintainable testing strategies, do not hesitate to contact me.