XML Formatter

XML arrives in two states and neither is readable: one enormous line from an API or a message queue, or a file whose indentation stopped matching its structure three edits ago. Both hide the same thing — which element is inside which.

This tool indents the structure, checks that the document is well formed and pins the first fault to a line and column, and minifies back down when you need the payload small. It runs entirely in your browser, which matters because XML tends to carry the parts of a system that are not meant to be public.

Every tag closed, and closed by the right tag — </b> where <a> is open is reported with both names, because that is the fault people spend longest hunting. Exactly one root element. Attribute values quoted, no attribute given twice on the same element, and no literal < inside a value.

A bare ampersand is checked too, and it is the most common fault in hand-edited XML by a distance. A URL pasted into a value as ?a=1&b=2 makes the document invalid; it has to be written &amp;. The check accepts named entities, &#65; and &#x41;, and rejects everything else.

What it does not do is validate against a DTD or an XSD. Well formed means the syntax holds together; valid means the content matches a schema, and they are different questions. A tool that quietly conflated them would tell you a document is fine when your integration partner is about to reject it.

Whitespace between two elements is presentation: no parser reading <order><id>1</id></order> cares whether there was a newline between the tags. Whitespace inside a text node is data, and a formatter that reflows it has changed the document.

So an element whose children are all elements gets its children put on their own lines, and an element holding text or a CDATA section is copied out exactly as it stands — every space, every line break, byte for byte. That is also true of an element whose entire content is whitespace: <pad> </pad> has three spaces of content, and tidying them away would be an edit, not a format.

The same applies to xml:space="preserve", which is the standard way of saying so explicitly. Elements carrying it are never re-indented.

CDATA is the usual casualty. Its whole purpose is to hold characters the parser must not interpret — a fragment of HTML, a script, a string full of angle brackets — so re-indenting inside one corrupts the payload. Here the section is copied through byte for byte, brackets and all.

A DOCTYPE with an internal subset is the second: <!DOCTYPE note [ <!ENTITY nbsp "&#160;"> ]> contains > characters of its own, so a formatter that stops at the first one truncates the declaration. Processing instructions, including the XML declaration and any <?xml-stylesheet?>, are preserved in place. Namespace prefixes are just part of the element name and are never rewritten, so soap:Envelope stays soap:Envelope.

For anything sent over a network repeatedly: a SOAP request, a sitemap, an ad-tech payload. Indentation on a document with a few thousand elements is easily a fifth of the bytes, and it is bytes the receiving parser will throw away.

Two caveats. Whitespace inside a text node still cannot be touched, so a document that is mostly prose will not shrink much. And if the transport already applies gzip — nearly all of them do — the extra saving from minifying is a few percent rather than the raw twenty, because repeated indentation is exactly what a compressor is best at.