{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

Parser{{ parserBadgeValue }} Result{{ resultBadgeValue }} Stored{{ storedBadgeValue }}
The default sample is namespaced XML with two book records.
{{ sourceFileStatus || 'Drop XML, HTML, or TXT onto the textarea.' }}
Choose the parser used by the runtime where this XPath will run.
Auto resolves common string, number, and boolean functions; other expressions use nodes.
The result updates as the source, expression, namespaces, or selected modes change.
Examples target the bundled catalog and cover nodes, attributes, count, and string output.
Explicit mappings override matching root declarations. Blank and # comment lines are ignored.
The match ledger always keeps path, node kind, name, and compact value evidence.
The default keeps the first 100 node rows. Raise it only for an intentionally broad result.
rows
Server-side snippets assume strict XML and include the current namespace mappings.
{{ matchedOutput }}
IndexPathKindNameValueCopy
{{ row.index }}{{ row.path }}{{ row.kind }}{{ row.name }}{{ row.value }}
CheckStatusEvidenceNext actionCopy
{{ row.check }}{{ row.status }}{{ row.evidence }}{{ row.action }}

The chart renderer is unavailable. Match counts remain available in the ledger and audit.

{{ runtimeSnippet }}
SelectorPurposeExamplePortabilityCopy
{{ row.selector }}{{ row.purpose }}{{ row.example }}{{ row.portability }}
Extensible Markup Language (XML) Converter Turn XML into structured JSON or record-based tables with local parsing, record-path selection, whitespace controls, and schema checks.
JSONPath Tester Test JSONPath expressions on local JSON, inspect matched values with paths and pointers, and distinguish empty results from syntax errors.
XML Diff Comparator Compare XML as parsed structure with keyed or positional node matching, namespace and whitespace policies, and exact path-level change evidence.
JSON Formatter Format JSON for review or transport, inspect its structure and byte size, and flag duplicate keys or precision risks before reuse.

XML can visibly contain an element and still return no XPath match. The usual cause is its namespace: an unprefixed name in an XPath 1.0 expression selects elements in no namespace, not elements covered by the document's default namespace. Binding a prefix to the namespace URI changes the expression, but it does not change the document.

XPath works over a parsed tree rather than the original markup string. Elements, attributes, text nodes, comments, processing instructions, and the document root are different node kinds. A location path moves through relationships such as child, descendant, parent, or attribute, while predicates narrow the current node set by value or position.

Parser choice comes before selector choice. Strict XML parsing rejects malformed markup and preserves XML naming rules. HTML parsing repairs page markup into a browser-style document tree, which can add wrappers, close missing tags, or move nodes. The same source text can therefore produce different trees and different XPath results.

Node result
One or more elements, attributes, text nodes, or other nodes that can be inspected individually.
Scalar result
One string, number, or boolean returned by an expression such as string(), count(), or boolean().
Predicate
A bracketed condition such as [@genre="fiction"] or [1]; XPath positions are one-based.

A broad descendant path such as //title is convenient for discovery, yet it can start matching navigation, metadata, or nested records after a document changes. Anchored paths and namespace-qualified names are usually more stable. When a scalar function collapses several nodes into one value, inspect the underlying node selection first so the single result does not hide an overbroad path.

XPath portability depends on the target runtime. Browser DOM evaluation follows XPath 1.0 result semantics, while other libraries may use later XPath versions, different HTML trees, or different namespace registration APIs. A selector is ready for production only after it is tested against representative source in the actual runtime.

How to Use This Tool:

Match the target parser and namespace context first, then evaluate the expression and inspect the returned node evidence.

  1. Paste an XML or HTML document, drop a supported file, or browse for one XML, HTML, or text file up to 2 MiB.
  2. Choose Strict XML for well-formed XML or HTML document for page markup that should be repaired as a browser document.
  3. Enter the XPath expression. The sample buttons demonstrate namespaced element selection, attributes, count(), and string().
  4. Add one prefix=URI namespace mapping per line. Blank lines and lines beginning with # are ignored; explicit mappings override matching declarations found on the root element.
  5. Leave Result type on Auto detect or force a node snapshot, string, number, or boolean when the target runtime expects that category.
  6. Choose serialized nodes, text values, or generated paths for matched output. Raise the 10 to 500 Match limit only when the total count shows that useful node rows were omitted.
  7. Check the match ledger and expression audit before copying a runtime snippet. Resolve parser errors, namespace warnings, empty results, or truncation first.

Interpreting Results:

For node results, verify the total count together with each stored path, node kind, name, and compact value. The result limit affects stored evidence, not the total snapshot length. A total of 800 with a limit of 100 means 700 matched nodes are omitted from the visible ledger.

For string, number, or boolean results, the single scalar row is the expression result rather than proof of one source node. Run the underlying path as a node snapshot when repeated elements or namespaces could change the meaning. For example, count(//bk:book) returning zero may indicate a missing namespace binding rather than an empty catalog.

An empty node snapshot is a valid XPath outcome after successful parsing and evaluation. Check parser mode, element-name case, predicate order, and namespace prefixes before concluding that the source lacks the data.

Technical Details:

XPath 1.0 evaluates an expression from a context node with a namespace resolver and a requested result type. Abbreviated syntax hides the full axis machinery: //bk:title performs a descendant search for title elements in the namespace bound to bk, while //bk:book/@id switches to the attribute axis for the final step.

Transformation Core:

Stage Rule Failure or review cue
Parse document Strict XML reports malformed markup; HTML mode builds a repaired browser document. Fix a strict parse error or inspect the repaired HTML tree before editing the XPath.
Build namespace context Root declarations are collected and explicit prefix=URI lines are applied afterward. A default XML namespace still needs a prefix in the expression.
Choose result category Auto mode recognizes common numeric, string, and boolean function openers; other expressions use an ordered node snapshot. Force a result category when automatic recognition does not match the target runtime.
Evaluate The browser XPath 1.0 engine applies the expression from the document node with the namespace resolver. Syntax, unsupported functions, or unresolved prefixes produce an XPath error.
Project evidence Node results store generated paths, kinds, names, compact values, and serialized content up to the selected limit; scalar results store one value row. Compare total and stored matches before relying on an incomplete ledger.

Rule Core:

Rule Example Consequence
Absolute path starts at the document root /catalog/bk:book The top-level element and namespace must match exactly.
Double slash searches descendants //bk:title Convenient for discovery but broader and more sensitive to new nested content.
Attributes are nodes //bk:book/@id The ledger reports an attribute kind and value rather than serialized element markup.
Predicates run in sequence //bk:book[@genre="fiction"][1] The first position is taken after the genre filter, and positions begin at 1.
Scalar functions collapse structure string(//bk:book[1]/bk:title) The returned string no longer shows the selected node's kind or full serialized form.

Generated paths use element names with one-based sibling positions. Attributes append /@name, and text nodes append a one-based /text()[n] step. These paths are review evidence produced from the parsed tree; they are not promised to be the shortest or most stable selector for later use.

Source is limited to 2 MiB, expressions to 4,096 characters, and stored node rows to the selected 10 to 500 limit. Root namespace declarations and manual mappings contribute to the namespace count. Manual mappings can deliberately replace a prefix discovered on the root.

Runtime snippets are provided for browser JavaScript, Python lxml, Java JAXP, PHP DOMXPath, .NET XPathNavigator, and Ruby Nokogiri. They are starting points, not portability proof; server-side snippets assume strict XML and carry the current manual namespace mappings.

Privacy and Portability Notes:

The document, expression, and namespace mappings are evaluated in the browser. Selected files are read locally rather than uploaded for XPath evaluation. Copied nodes, exported ledgers, runtime snippets, and screenshots can still contain confidential source values.

  • Match the parser mode and XPath version used by the target system.
  • Carry namespace mappings with the expression instead of assuming prefixes have universal meaning.
  • Use redacted documents when feeds contain credentials, customer records, tokens, or unreleased content.

Worked Examples:

Namespaced catalog titles

With the sample and bk=urn:books, //bk:book/bk:title returns two element nodes. The ledger shows their one-based paths and title text. Changing bk to the wrong namespace URI makes the selection empty even though the title elements remain in the XML.

Inspect nodes before counting

First run //bk:book as a node snapshot and confirm the two book paths. Then run count(//bk:book) to obtain the number 2. The first check proves what the scalar expression is counting.

References: