XML Formatter and Validator

What an XML formatter does

XML carries structure in its tags, not in its layout, so a document that a machine wrote is often a single line tens of thousands of characters long. Formatting parses that text into a document tree and prints it back with one node per line and indentation that follows the nesting, which makes the hierarchy — the part you actually need to understand — visible immediately.

Because formatting requires parsing, it is also a well-formedness check. If the output comes back indented, the document is structurally sound. If it does not, the browser's XML parser reports what went wrong and roughly where, which is usually enough to find an unclosed tag or a stray ampersand in a document you did not write.

Well-formed versus valid

These are different claims and the distinction causes real confusion. A well-formed document obeys XML's syntax rules: one root element, every start tag matched and correctly nested, attribute values quoted, no duplicate attributes, and reserved characters escaped. A valid document is well-formed and conforms to a schema — an XSD, a DTD or a RELAX NG grammar — that says which elements may appear where, how many times, and what their content may be. This tool checks well-formedness, which is what you need when a document will not parse at all. Schema validation requires the schema, and a service that rejects a well-formed document is usually telling you about a validity problem instead; that is the difference between a 400 Bad Request for unparseable input and a 422 for input that parsed but did not satisfy the rules.

Why XML documents fail to parse

The five predefined entities are worth memorising because they are the only ones XML gives you for free: &, <, >, " and '. Everything else needs a numeric character reference or a DTD declaration, which is why documents copied out of an HTML page so often fail. If the text you are escaping is destined for a web page rather than an XML document, the HTML encoder covers the wider set of named entities HTML allows.

Encoding declarations that lie

The declaration <?xml version="1.0" encoding="UTF-8"?> is a statement about the bytes in the file, not an instruction to convert them. If the file is actually Latin-1, the parser will fail on the first accented character with an invalid-byte error. The fix is always to correct the file's real encoding rather than to edit the declaration. A byte-order mark before the declaration causes a similar class of failure, since nothing may precede it.

Formatting, minifying and whitespace

In XML, whitespace between elements is generally insignificant, but whitespace inside an element that contains text is part of the content. A formatter that reindents everything indiscriminately will change the data — adding newlines inside a <description> that then show up in whatever renders it. This formatter therefore indents only where an element's children are themselves elements, and leaves an element whose content is text exactly as it is, on a single line. Mixed content, where text and elements are siblings, is left alone entirely for the same reason.

Minify performs the inverse: it removes whitespace-only text nodes between elements and emits the document with no line breaks. That is what you want before putting a document into a SOAP envelope, a message queue payload or a request body in the API tester. Note that minifying is not always byte-reversible with formatting — if the original had whitespace-only nodes that were meaningful to a downstream consumer, they are gone. For XML that is almost never a problem, and for the cases where it might be, keep the original.

Comments, CDATA sections and processing instructions all survive both operations. CDATA in particular is worth understanding: <![CDATA[ … ]]> tells the parser to treat everything inside as raw text, which is how documents embed a chunk of HTML, a script or an SQL statement without escaping every bracket. Its one limitation is that the sequence ]]> cannot appear inside it.

Comparing and converting

Two XML documents that should be identical but are not are best handled by formatting both with the same indentation and then running them through the diff checker — without normalising the layout first you will be diffing formatting rather than content. If you are migrating a SOAP integration to a JSON one, format the XML here to understand the structure, then rebuild the payload and check it with the JSON formatter. There is no lossless automatic XML-to-JSON mapping, because XML distinguishes attributes from child elements, allows repeated element names where JSON needs an explicit array, and carries namespaces that JSON has no place for — any converter has to invent conventions for all three, and the conventions differ between tools.

Namespaces

A namespace declaration such as xmlns:soap="…" binds a prefix to a URI, and it is the URI that identifies the vocabulary, not the prefix. Two documents using different prefixes for the same URI are equivalent, which is a frequent source of "but they look different" confusion when diffing SOAP messages. The URI does not need to resolve to anything; it is an identifier, not an address.

Frequently asked questions

Related tools and reference