XML Formatter and Validator: Pretty Print XML

What this XML formatter does

Paste XML and it gets parsed by your browser's built-in XML parser, the same one that handles SVG and RSS feeds. If the document is well-formed, the tool walks the element tree and writes it back out with one element per line and consistent indentation. If it is not well-formed, you get the parser's error with a line and column instead of a half-formatted mess.

No library, no server. The parse happens in this tab, which matters when the XML is a SOAP response with account numbers, a SAML assertion, or an internal config file. Nothing is uploaded or logged.

Well-formed is not the same as valid

Well-formed means the document follows XML's grammar: one root element, every tag closed, tags properly nested, attribute values quoted, and special characters escaped. That is what this tool checks.

Valid is a stricter idea: the document also matches a schema (XSD, DTD, or RelaxNG) that says which elements are allowed where. A file can be perfectly well-formed and still fail schema validation because an element is missing or out of order. Schema validation needs the schema file and a validating parser, which browsers do not ship.

The errors you will actually see

Mismatched tag: <name>Ada</Name> fails because XML is case-sensitive. Opening and closing tags must match exactly.

Unescaped ampersand: <company>Smith & Sons</company> fails. Write &amp; instead, or wrap the text in a CDATA section. The same goes for a literal < inside text, which must be &lt;.

Multiple roots: two top-level elements side by side is not a document. Wrap them in a single parent.

Content before the declaration: <?xml version="1.0"?> must be the very first thing in the file. Even a blank line or a byte-order mark in the wrong place before it triggers an error in strict parsers.

Undeclared namespace prefix: <media:cover/> needs xmlns:media="..." on it or an ancestor. The parser rejects prefixes it cannot resolve.

Worked example

Input on one line: <catalog><book id="bk101"><author>Gambardella, Matthew</author><price currency="USD">44.95</price></book></catalog>. Formatted with 2 spaces, catalog sits at the left edge, book is indented two spaces, and author and price are indented four with their text kept on the same line as their tags. Empty elements are written in the short self-closing form, like <cover/>.

Comments, CDATA sections, processing instructions, and the XML declaration are preserved. Attribute order stays as written, and special characters are re-escaped correctly on the way out.

Pitfalls

Whitespace in mixed content. Pretty-printing adds line breaks between elements and trims whitespace-only text. For data XML (configs, API payloads, feeds) that is exactly what you want. For document-style XML where text and inline tags mix, such as DocBook, XHTML paragraphs, or <p>Hello <b>world</b></p>, the formatter will move the <b> onto its own line, which changes the rendered spacing. Format those by hand, or only minify them.

xml:space="preserve". Some formats mark elements whose whitespace must not change. This tool does not special-case that attribute, so keep the original for those sections.

DOCTYPE entities. Browsers do not load external DTDs, so custom entities defined in an external DTD (like &nbsp; in some legacy files) will be reported as undefined. Replace them with numeric references such as &#160;.

Huge files. Everything runs on your device, so a 50 MB export will be slow. For files that size, use xmllint --format file.xml on the command line.

Minify versus format

Minify removes the whitespace between tags and puts the document on one line. It is handy for embedding XML in a JSON string, a test fixture, or an environment variable. Over the network, gzip compresses indentation so well that minifying rarely saves much, so keep the readable version in source control.