XML Formatter
Free XML beautifier. Format XML files, fix indentation, and validate structure. Visualize nested XML data clearly.
About XML Formatter
This page runs the Prettier XML plugin in your browser at two-space indentation and an 80-column print width. The document is parsed into a node tree and printed fresh, so a feed or configuration file that arrived as a single unbroken line comes back as a proper hierarchy.
One setting drives most of the behaviour: whitespace sensitivity is switched off. Without that, the printer assumes every space between elements might be meaningful and returns the document essentially as it arrived, which looks like the formatter doing nothing. With it off, text nodes are free to be re-wrapped and indented. The trade-off is real and you should know it: mixed content is reflowed. A paragraph element holding text, an inline child and a trailing word comes back with each part on its own line, and the runs of spaces around them change. For data-carrying XML — configuration, feeds, API payloads, build files — that is exactly what you want. For document-style XML such as DocBook or XHTML prose, check the result before saving over the original.
Where whitespace is explicitly declared significant, it is respected: an element carrying xml:space="preserve" keeps its interior spacing byte for byte, and CDATA sections are copied through untouched, including any angle brackets inside them. Entity references are left encoded rather than resolved, so an ampersand entity stays an ampersand entity. Comments, processing instructions, the XML declaration and a DOCTYPE line are all preserved. Namespace prefixes and xmlns declarations are printed as written.
Attributes stay on the element line until the line passes the 80-column target, at which point every attribute moves onto its own indented line and the closing bracket drops below them. Empty elements are normalised to the self-closing form with a space before the slash. Two-space indentation is used throughout.
The parser requires closed, quoted markup and will not guess. A tag left unclosed, an HTML void element such as a bare line break tag, an unquoted attribute value, or two root elements at the top level all stop the run. One gap is worth knowing about: mismatched end tags are not caught. Feed it a document where tags overlap rather than nest and it formats without complaint, reproducing the crossed tags in the output — so a clean format is evidence that the document parses, not proof that a validating XML parser will accept it. Be warned too that the error text is not uniformly helpful: two root elements report a real line and column with a code frame, while an unterminated element reports the internal token it expected and a position of NaN:NaN. When that happens, bisect the document — paste the first half, then the second — to find the branch that will not parse.
Real Indentation, Not A Reflow
The document is parsed and re-emitted, so a feed or a configuration file delivered as one enormous line comes back as a two-space indented tree rather than the same line with a few breaks added.
Preserves What Must Be Preserved
CDATA blocks, entity references, comments, processing instructions, DOCTYPE lines and any element marked xml:space="preserve" all survive the round trip exactly as written.
A Parse Check For Free
Because it refuses to print anything it cannot parse, a successful format tells you every element is closed, every attribute is quoted and there is a single root — a useful smoke test on hand-edited config. It stops short of full well-formedness: mismatched end tags slip through.
Frequently Asked Questions
Why did my HTML fail here?
XML has no void elements. A line break or image tag written without a closing slash is valid HTML but not valid XML, so the parser stops. Attribute minimisation such as a bare disabled attribute fails for the same reason. Use the HTML formatter for HTML — it applies browser end-tag inference and knows which elements are self-closing.
The error message has no line number. How do I find the problem?
Some parse failures report a position and some report only the token the grammar expected, followed by a useless NaN:NaN. When you get the unhelpful kind, bisect: paste the top half of the document and format, then the bottom half. Whichever half fails contains the fault, and repeating the split narrows it to a single element in a few rounds. The usual culprit by far is a tag left unclosed — often an HTML void element that slipped into the file.
Will formatting change my data?
Element names, attribute names, attribute values, CDATA and entity references are unchanged. What can change is whitespace inside elements that hold a mixture of text and child elements, because whitespace sensitivity is deliberately turned off so the document can be indented at all. Pure data XML is unaffected in any way that matters; prose-bearing XML should be eyeballed afterwards.
Does it validate against my schema or DTD?
No. It checks only as much as printing requires — that every element is closed, that there is exactly one root element, and that attribute quoting is legal. It does not verify that end tags match their start tags, and it does not fetch or apply an XSD, RELAX NG schema or DTD, so a document that formats cleanly can still be rejected by a validating consumer for having crossed tags, or the wrong elements in the wrong order.
Can it handle SVG, RSS, SOAP or a POM file?
Yes. All of those are ordinary well-formed XML and format normally, including namespace prefixes and default namespaces. SVG path data is an attribute value, so it is preserved exactly rather than re-wrapped.
Are entities and special characters decoded?
No, and that is intentional. An escaped ampersand or angle bracket stays escaped, and numeric character references stay numeric. Decoding them would change the document, and in several cases would make it invalid. If you need the decoded text, extract it after parsing rather than expecting the formatter to do it.
Should I use this or the HTML formatter for an XHTML file?
Either can work, and they give different results. The XML path enforces well-formedness strictly and treats every element the same, which is what you want for a file that will be consumed by an XML parser. The HTML path knows that some elements are inline and refuses to add whitespace inside them, which is what you want if a browser will render the file. If the document is served as HTML, format it as HTML; if it is validated as XML, format it here.
How big a document can it handle?
There is no coded cap, but parsing builds a full tree in memory and the editor holds the text as well, so a few hundred kilobytes is comfortable and a multi-megabyte export will make the tab stall. For very large feeds, format a representative fragment to learn the structure rather than the whole file.