XPath Tester

Introduction

XPath is a compact query language for selecting parts of an XML-style document tree. It is common in integration tests, XML feeds, SOAP payloads, browser automation, scraping prototypes, and legacy data workflows where the question is not just whether the document is valid, but whether a selector reaches the exact element, attribute, text node, or scalar value expected.

A good XPath test confirms three things at once: the document was parsed the same way as the target runtime, namespace prefixes resolve to the intended namespace URIs, and the expression returns the expected result type. A selector that works on a tiny sample can still fail against production markup when a default namespace, an HTML parser repair, a predicate position, or a forced string or number result changes the meaning.

XPath 1.0 remains a practical baseline because many browser and XML runtimes still expose that version. It can select node sets and also compute strings, numbers, and booleans through functions such as string(), count(), and boolean(). Those scalar results are useful, but they can hide which node supplied the value unless the selector is also checked as a node query.

The safest habit is to treat every XPath expression as evidence to inspect, not just a string to copy. Review the matched nodes, the generated paths, the parser status, and any namespace warnings before moving the selector into tests, transformations, scrapers, or application code.

How to Use This Tool:

Start with a representative document, then keep the parser mode and result type aligned with the place where the XPath will run.

1. Paste markup into XML or HTML document, drop an XML, HTML, or TXT file onto the editor, or use Browse file. Load sample fills in a namespaced catalog example for a first pass.
2. Enter one selector in XPath expression. The preset buttons show common paths for the sample, including element matches, attribute matches, count(), and string().
3. Add Namespace prefixes when the document uses qualified names. Each mapping uses the visible form prefix=URI, such as bk=urn:books. Root namespace declarations are also read when available.
4. Choose Parser mode before trusting the result. Strict XML stops on well-formedness problems, while HTML document lets the browser build a document tree from page-style markup.
5. Leave Result type on Auto detect for normal use, or force Node snapshot, String value, Number value, or Boolean value when you need to confirm a specific runtime coercion.
6. Set Matched output to Serialized nodes, Text values, or XPath paths depending on what you need to compare or copy. If a large selector is trimmed, raise the Advanced Match limit or narrow the expression.
7. Review Matched Output, Node Match Ledger, and Expression Audit together. Parser errors, missing namespace mappings, empty matches, and truncation warnings should be fixed before copying the XPath.

Interpreting Results:

The summary number is useful, but the ledger is the trust check for node results. Matched Output shows the selected content in the chosen view, while Node Match Ledger records the match index, generated path, node type, node name, and compact value. If those paths point to the wrong branch, the expression is not ready even when the match count looks correct.

Scalar results need a different check. A String value, Number value, or Boolean value can be exactly what the expression asks for, but it may also mask which node supplied the value or whether only the first matching node mattered. When confidence matters, test the same path as a node query first, then switch to the scalar function.

A clean parser status does not prove the selector is portable. Strict XML and HTML document can build different trees from the same text, namespaced elements require matching prefix bindings, and XPath comparisons are case-sensitive for names. Use Expression Audit to check parser, namespace, match limit, and processing-location evidence before moving the expression elsewhere.

No match means the expression returned no node rows or scalar value in the current parse context. Check the document shape, namespace prefixes, predicate positions, result type, and spelling before assuming the source document lacks the data.

Technical Details:

XPath addresses a logical document tree rather than the raw characters in the source text. Elements, attributes, text, comments, and processing instructions are nodes, and a location path selects nodes by applying axes, node tests, and predicates from a context node. The familiar // abbreviation searches descendants, @ addresses attributes, and bracketed predicates filter a candidate set by position or condition.

XPath 1.0 has four main result categories: node sets, strings, numbers, and booleans. Browser-facing evaluators expose those categories through result types, so a path such as //bk:book behaves differently from count(//bk:book) or string(//bk:book[1]/bk:title). Choosing the wrong result type can turn a valid expression into an error or make a multi-node result look like one scalar value.

Namespaces are resolved by URI, not by the visual prefix alone. The prefix in an XPath expression is a shorthand that must be bound to the same namespace URI used by the document. Default namespaces in XML are especially easy to miss because an unprefixed XPath name does not automatically mean “use the document default namespace” in many XPath environments.

Transformation Core

A repeatable XPath test moves from parse context to typed result evidence.

1. Parse the pasted or selected document as strict XML or as an HTML document tree.
2. Collect namespace mappings from the root and from the manual prefix=URI lines.
3. Choose the requested XPath result type from the selected mode, or infer a scalar type for common scalar functions when auto detect is selected.
4. Evaluate the expression against the parsed tree with the namespace resolver in place.
5. For node results, store rows up to the current match limit with path, type, name, value, and serialized evidence. For scalar results, store one value row.
6. Build audit checks for parser status, XPath status, namespace readiness, match-limit truncation, and local processing.

Worked Mechanism Path

With the sample catalog, //bk:book/bk:title uses the bk prefix mapping to find title elements under book elements in the urn:books namespace. The node result produces two ledger rows, one for each title, with generated paths and text values. Switching the expression to count(//bk:book) changes the result category to a number and returns one scalar row with the value 2.

Privacy Notes:

The document text, selected local file, XPath expression, and namespace mappings are evaluated in the current browser session for the current test. The audit includes a processing-location check so you can confirm that the active evaluation does not need a backend request.

Local evaluation does not make sensitive data harmless. Treat pasted XML, HTML, tokens, customer records, and credentials as confidential, use a browser session you trust, and clear the document field when you are done reviewing private material.

Worked Examples:

Namespaced book titles

The sample catalog contains two bk:book elements and the mapping bk=urn:books. The expression //bk:book/bk:title returns 2 node matches, and Node Match Ledger lists each title element with its path, node type, name, and text value. Removing the namespace mapping turns the same expression into a namespace problem rather than a missing-data signal.

Counting records before an import test

A partner XML file should contain 120 order records. Using count(//ord:order) with Result type on Auto detect produces a Number value. If the value is 0, check the Namespace resolver row in Expression Audit before changing the path, because the record element may be namespaced.

HTML markup copied from a page

A copied table fragment may parse poorly in Strict XML because HTML often omits closing tags or uses markup that is not XML. Switching Parser mode to HTML document can build a browser-style tree, then Matched Output and Node Match Ledger show whether the selector targets the normalized structure you intend.

Large selector trimmed by the match limit

A broad expression such as //item may match hundreds of nodes. If Expression Audit reports Truncated, the XPath did match more nodes than the ledger kept. Raise Match limit up to the needed row cap or make the predicate more specific before exporting evidence.

FAQ:

Glossary:

XPath

A query language for addressing nodes and scalar values in an XML-style document tree.

Node snapshot

A stored list of matched nodes, useful for reviewing paths, node names, and values.

Predicate

A bracketed filter that narrows a node set by position or condition.

Namespace prefix

A short name in the XPath expression that must map to the document's namespace URI.

Scalar result

A single string, number, or boolean value returned by an XPath expression.

References:

• XML Path Language (XPath) Version 1.0, W3C, 16 November 1999.
• Document Object Model XPath, W3C, 26 February 2004.
• Namespaces in XML 1.0 (Third Edition), W3C, 8 December 2009.
• HTML Standard: DOMParser parseFromString, WHATWG.