XML Viewer & Formatter

About XML Viewer & Formatter

Paste an XML document — an RSS feed, a SOAP envelope, a Maven POM, an Android manifest, a sitemap, an SVG, a bank statement export — and read it three ways: as a collapsible tree you can fold down to the shape of the thing, as pretty-printed text with the indentation you choose, or minified onto one line. Well-formedness is checked as you type, and when the parser objects it tells you the line and column it stopped at rather than just refusing. XML arriving from a real system is usually either minified into a single unreadable line or indented by whoever generated it rather than by you, and both problems are the same problem: you cannot see the structure. The tree view fixes it by hiding the structure you are not looking at, the formatter by rewriting the whitespace, and neither one touches the data. Everything runs in your browser tab on the browser’s own XML parser, so a signed payload or a customer export is never uploaded.

Key features

• Three views of the same document — an interactive tree, formatted text, and minified text — switched with one click and always in sync with the input
• Collapsible tree with Expand all and Collapse all: fold a 4,000-line feed down to its root and open only the branch you care about
• Well-formedness checked live, with the parser’s own message plus the line and column, and the offending line marked in the input pane
• Syntax colouring in both panes and in the tree — tags, attribute names, attribute values, text, comments and CDATA each read differently
• Your choice of indentation: 2 spaces, 4 spaces, or tabs
• Minify that is still XML — whitespace between elements goes, the document stays well-formed, and the output reports how much smaller it got
• Long start tags wrapped one attribute per line, so an element carrying eight namespaces stays readable instead of running off the pane
• Options for the details that differ between generators: self-close empty elements (<notes/>) or write them out (<notes></notes>), keep or strip comments, keep or drop the XML declaration, and sort attributes alphabetically for diffing
• Namespaces, prefixes, CDATA sections, processing instructions and DOCTYPE declarations all survive the round trip intact
• Mixed content is left alone — an element holding both text and child elements is never re-wrapped, so the spaces inside <p>see <b>this</b> page</p> stay exactly where they were
• Document stats above the output: element count, attribute count, distinct tag names, and nesting depth
• Runs entirely in your browser on the built-in XML parser — no upload, no server, and it works offline once the page has loaded

How to use it

1. Paste your XML into the left pane, or type it there directly.
2. If it is not well-formed, read the error under the output — it names the line and column — and fix the marked line in the input.
3. Stay on Tree to explore the document: click any element with children to fold or unfold it, or use Collapse all to see just the top level.
4. Switch to Formatted for pretty-printed text, and pick 2 spaces, 4 spaces, or tabs.
5. Switch to Minified to strip the layout whitespace for a payload or a config value.
6. Adjust the switches if the output has to match a house style — self-closing tags, comments, the XML declaration, attribute order — then copy the result.

Tips & common mistakes

• Collapse all first on a document you have never seen. What you get is the top level and nothing else, which is the fastest way to learn the shape of an unfamiliar feed — far faster than scrolling a formatted version of it.
• The error line is the line the parser gave up on, not always the line with the mistake. An unclosed <item> on line 12 is reported at the point the parser meets a closing tag that cannot match, which may be hundreds of lines later. Work backwards from the reported line to the last tag you know was closed.
• "Not well-formed" and "invalid" are different failures. This tool checks well-formedness — tags nested and closed correctly, one root element, attributes quoted, & and < escaped. It does not check the document against a DTD or an XSD, so a document that is perfectly well-formed here can still be rejected by a schema validator for having the wrong elements in the wrong order.
• Unescaped ampersands are the single most common cause of a document failing here. A raw & in text or in an attribute — typically in a URL like ?a=1&b=2 — has to be written &amp;, because XML reads & as the start of an entity reference. The parser reports it as an unterminated entity, which is not an obvious description of the problem.
• Sort attributes before diffing two documents. Attribute order carries no meaning in XML, but a text diff does not know that, so two identical documents from two generators can diff as different on every line. Sorting both and formatting both with the same indentation reduces the diff to the changes that matter.
• Turn comments off to see the document a machine sees. Generated XML — POMs, manifests, exported configs — is often more comment than content, and stripping them makes the actual structure visible in a fraction of the lines.
• Minifying is safe for data XML and risky for document XML. Whitespace between elements is layout and is dropped; whitespace inside an element that mixes text and markup is content and is kept. If your XML is records and fields, minify freely. If it is prose with tags in it, check the result before shipping it.
• The declaration switch matters more than it looks. A stray <?xml ...?> anywhere but the very first character of a file is itself a well-formedness error, which is why an XML fragment being embedded into another document usually needs it turned off — and why a standalone file usually needs it on.
• Namespace prefixes are kept exactly as written rather than normalised. A document using soap: and one using env: for the same namespace stay different here, because rewriting a prefix is a change to the document that only you can decide is safe.
• A file that starts with a byte-order mark or a blank line before the declaration will fail to parse. Both are invisible in most editors; if a document looks perfect and still will not parse at line 1, delete everything before the first < and try again.
• Once the structure is clear, send the document on: the XML to JSON converter turns it into JSON for code that would rather not carry an XML parser, and the JSON to XML converter comes back the other way.

Related tools