XML Formatter and Validator

What this tool does

It indents, minifies and validates XML right in your browser. You paste a document that arrives on a single line or with wrecked indentation and it hands it back readable, pointing at the error if it is not well formed.

What sets it apart from most is what it preserves. Nearly every formatter parses the XML, builds a tree and serialises it again; along the way it drops comments, CDATA sections and the opening declaration. Here the formatter works on the text, so what was there stays there.

Well formed is not the same as valid

This is the distinction that causes the most confusion, and it is worth having clear before wrestling with an error.

Well formed means it follows XML’s syntax rules: every opened tag is closed, nesting does not cross over, there is a single root element, attribute values are quoted and reserved characters are escaped. That is what this tool checks.

Valid additionally means it matches a specific schema — an XSD or a DTD: that the elements are the ones that schema expects, in the order it expects and with the types it expects. That can only be checked with the schema in hand, and it differs per document.

An invoice can be perfectly well formed and still be rejected by a tax authority because it is not valid against its XSD. They are two different filters, and this is the first one.

Why the error points below the actual problem

An XML parser reads start to finish and only notices something is wrong when it reaches an impossible point. If you leave out a </item>, it happily keeps reading, and the error surfaces much later, when it finds a closing tag that does not match what it had open.

The practical consequence: search from the reported line upwards, not downwards. The real problem is almost always earlier.

The three cases that come up again and again:

1. An unclosed tag. The classic.
2. Crossed nesting, like <a><b></a></b>. Browsers forgive this in HTML; XML does not.
3. A bare & in the text. In XML it must be written &, because on its own it starts an entity. It is the most common error in documents generated by concatenating strings.

When to format and when to minify

Format when the destination is a human: reading a SOAP response, reviewing an inherited pom.xml, understanding an RSS feed, debugging a tax document.

Minify when the destination is the network or storage: whitespace between tags adds nothing to the document’s meaning and does take space. In a deeply nested XML, indentation can be a third of the file.

One nuance: minifying here removes whitespace between tags, never inside an element’s content. If your document has text with meaningful line breaks, they are respected.

About the validation

The check relies on fast-xml-parser (MIT licence), which returns the reason with line and column. The formatting and minifying are our own, precisely so we can preserve what a parse-and-serialise cycle would throw away.