Pretty-print or minify XML, see well-formedness errors with their line, run XPath 1.0 queries with namespace support, and convert XML to JSON — all with the parser already inside your browser.
ns.Formatting XML is not just inserting newlines. Whitespace inside an element is data unless the schema says otherwise, so a naive pretty-printer that indents everything changes the meaning of <p>Hello <b>world</b></p>. This tool parses the document with the browser's DOMParser, then re-serialises the tree with a rule: an element whose children are all elements is broken across lines and indented; an element that contains text stays on one line with its text untouched. Comments, CDATA sections and processing instructions are preserved unless you strip them. Attribute order is preserved as written.
Enterprise APIs still return dense single-line XML. Paste the body here to see the structure, then use XPath to pull the one value you need — //soap:Fault/faultstring or //saml:Attribute[@Name='email']/saml:AttributeValue — without writing a parser for a one-off check.
"XML parsing error" from a library rarely says where. The browser's parser reports the line and column of the first problem, and the tool shows it with the offending line. The usual culprits are an unescaped & in text, a mismatched closing tag, an attribute without quotes, or a BOM or stray character before the <?xml declaration.
The JSON mode gives a compact object view: attributes as keys prefixed with @, text as #text when an element has both, repeated child elements collapsed into arrays. It is meant for reading and for quick scripts, not as a lossless conversion — namespaces, comments and element order across siblings of different names are not representable in a plain object.
Maven pom.xml, web.config, Android manifests, RSS and Atom feeds, SVG, plist — all XML, all readable here. For SVG, formatting is safe; for feeds, an XPath like //item[1]/pubDate answers "when did this last update" faster than opening a reader.
| Expression | Selects |
|---|---|
/order | The root element, only if it is named order |
//item | Every item element anywhere in the document |
//item[@qty > 1] | Items whose qty attribute is greater than 1 (numeric comparison) |
//item[2] | The second item child of each parent — not the second item overall; use (//item)[2] for that |
//item/@sku | The sku attribute nodes of every item |
//item/text() | The text nodes directly inside each item |
count(//item) | A number, not a node set |
//item[contains(., 'Widget')] | Items whose string value contains "Widget" |
//*[local-name()='title'] | Any element named title regardless of namespace — the escape hatch when prefixes are awkward |
//ns:entry/ns:title | Elements in the document's default namespace, using the ns prefix this tool binds for you |
Browsers implement XPath 1.0, so functions from XPath 2.0 and 3.1 — matches(), string-join(), for … return — are not available, and a query that uses them fails with a syntax error. The four result types are what XPath 1.0 has: a node set, a string, a number or a boolean, and the tool labels which one you got.
The most common reason an XPath returns nothing is a default namespace. An Atom feed declares xmlns="http://www.w3.org/2005/Atom" on its root, which puts every element in that namespace; //entry then matches nothing, because in XPath 1.0 an unprefixed name means "no namespace", not "any namespace". You must bind a prefix and write //ns:entry. This tool reads every xmlns and xmlns:prefix declaration on the root element and makes them available, binding the default namespace to ns; the badge above the query box lists what is bound. Prefixes declared deeper in the document are not automatically visible, which is a limitation of resolving from the root; local-name() works around it.
No. It checks well-formedness — that the document is syntactically correct XML with balanced, properly nested tags, quoted attributes and escaped characters — using the browser's parser. Validation against a schema (whether the elements and values are the ones a particular XSD allows) needs a schema processor, which browsers do not include. For that, use xmllint with --schema, or your platform's XML library.
Almost always a namespace. If the document's root declares a default namespace with xmlns="...", every unprefixed element is in that namespace, and an unprefixed name in XPath 1.0 matches only elements with no namespace. Use the ns prefix this tool binds to the default namespace (//ns:entry), the prefix shown in the badge for other namespaces, or //*[local-name()='entry'] to ignore namespaces entirely.
Because whitespace inside an element that contains text is part of the data. The formatter only re-indents elements whose children are all elements, where the whitespace between them is insignificant. An element with text content, or mixed text and elements, is left exactly as written, so a document that carries meaningful spacing in its text is not corrupted by pretty-printing.
No, and no XML to JSON mapping can be in general. XML has ordered mixed content, namespaces, comments, processing instructions and a distinction between attributes and child elements; JSON objects have unordered keys and no attributes. The mapping here is designed to be readable and to round-trip the common case of element-only data with attributes, using @ for attributes and #text for text, but it is a convenience view rather than an interchange format.
XPath 1.0, because that is what document.evaluate() in browsers implements. It covers the full 1.0 axis set, predicates, and the core function library (contains, starts-with, substring, normalize-space, count, sum, position, last, local-name, name and the rest). Functions and syntax added in XPath 2.0 and later, such as regular-expression matching, sequences and for-expressions, are not available.
No. Parsing uses DOMParser, XPath uses document.evaluate, and serialisation is JavaScript in the page; there is no server request. You can confirm this in the Network tab of your browser's developer tools or by using the tool offline. That matters for XML in particular, because SOAP responses, SAML assertions and configuration files routinely contain credentials and personal data.