XML Formatter / Minifier
Indent XML by tag nesting, or compress into a compact single line
XML formatter: validity requirements and the exception where formatting changes meaning
XML is far stricter than HTML
An XML parser does no tolerant inference; a single invalid XML fails to parse outright. For the formatted output to be re-parseable, it must satisfy these requirements:
| Requirement | Note |
|---|---|
| Unique root element | The whole document may have only one outermost element |
| Tags must close | No "<br> may be omitted" exception; either <br/> or <br></br> |
| Case sensitivity | <Name> and <name> are different elements; the closing tag must match exactly |
| Attributes must be quoted | Single or double quotes both work, but omission is not allowed |
| Special characters must be escaped | & becomes &, < becomes <, > becomes > |
| XML declaration must be first | Nothing — not even whitespace — may precede <?xml version="1.0" encoding="UTF-8"?> |
The fifth row is the most common cause of parse failure: in XML, & can only begin an entity, so a bare & in the body must be written as &. A & inside a URL parameter (such as ?a=1&b=2) placed directly into XML text will make parsing fail.
The exception where formatting changes meaning
This is important and often overlooked: the XML spec treats whitespace between elements as significant. Newlines and indentation that formatting inserts become part of the text nodes.
| Case | Consequence of formatting |
|---|---|
Pure element content (such as <a><b/></a>) | Usually no effect; most applications ignore inter-element whitespace |
| Mixed content (both text and child elements) | An inserted newline alters the text content and may break display or validation |
Text element (such as <name>Bob</name>) | A newline inside the tag becomes part of the value, breaking validation or comparison |
Element declaring xml:space="preserve" | Existing whitespace must be fully preserved; no re-indenting |
So the practical rule is: if the schema does not declare inter-element whitespace ignorable, formatting is a risky operation. Two cases to avoid especially:
- XML used for digital signatures. XML Signature (XMLDSig) signs the canonical form of the document; any whitespace change makes signature verification fail. Such documents must never be formatted.
- Documents with mixed content (such as XHTML, DocBook, SVG paragraphs containing text).
Also, the content inside a <![CDATA[...]]> section is raw text and must not be re-indented. This tool keeps CDATA content as-is.
Minification
Minification deletes whitespace and newlines between elements. The same condition applies: it is only safe once you are certain the whitespace is ignorable. A minified document does save some wire size (XML tags are highly repetitive, though the gain shrinks further under gzip).
Minification brings one side effect: problems become harder to debug. Keep an unminified version and use the minified artifact only for transfer.
Division of labour with XML-to-JSON
| Need | Use |
|---|---|
| Make XML tidy and readable | This tool |
| Verify XML is well-formed | This tool (fails on invalid); checking against a schema needs a dedicated tool |
| Convert XML into a JSON structure | The XML-to-JSON tool (browser parser, handles entities and CDATA correctly) |
| See which fields an XML fragment has | XML-to-JSON is more direct, but mind the attribute and single-value/array ambiguity |
How to use the tool
Paste XML, click format for hierarchical indentation or minify for a compact single line. It suits reading XML returned by an API, checking nesting depth, and tidying configuration files. Processing runs locally in your browser — API responses often contain business data, so local processing is a necessary default.
FAQ
How are extra spaces between tags handled?
When formatting, pure-whitespace text between tags is removed; only real text content inside tags is kept and indented.
Does minification change node order?
No. Minify only removes whitespace between tags; node and attribute order remain completely unchanged.