Format XML
Indent a wall of XML into something readable, or minify it back. Comments, CDATA sections and namespaces survive intact. Nothing is stored.
- Never stored
- No queue, no waiting
- No signup, no watermark
The formatted XML appears here.
How it works
Paste your XML
Or drop in an .xml, .svg, .rss or .xsd file. It is never stored.
Pick an indent
Two spaces, four, tabs, or minified to one line.
Copy or download
If the XML is broken, you get the line and column instead of a result.
Why re-indenting XML is riskier than it looks
Whitespace in XML is significant by default, and this is the thing that catches people out. Unlike JSON, where formatting is free, an XML parser is obliged to report the spaces and newlines between elements as text content — it is the schema, if there is one, that says they can be ignored. So re-indenting a document genuinely changes it, and for most configuration and data files nothing cares, while for documents with mixed content — text and elements side by side, as in XHTML or DocBook — it can alter what the document says.
Formatting here therefore leaves alone what must be left alone. An element carrying xml:space="preserve" keeps its contents exactly as written, because that attribute exists precisely to say so. CDATA sections are passed through untouched; they exist to hold text that must not be interpreted, and reformatting inside one would corrupt it. Entity references stay as references rather than being expanded into the characters they stand for.
Namespaces are preserved exactly as written — prefixes, declarations and the elements they are bound to. That sounds obvious and is not: a formatter that normalises prefixes, or moves declarations to where it thinks they belong, produces a document that is technically equivalent and that fails against tools matching on literal prefixes. Attribute order is kept too, although XML considers it meaningless, for the same reason — because a diff against the previous version is worth more than tidiness.
What is checked while formatting is well-formedness: every tag closed, correctly nested, one root element, legal characters, properly escaped ampersands and angle brackets. That is the lower of XML's two bars. A document can be perfectly well-formed and still be invalid against the DTD or schema that governs it, which no amount of formatting reveals.
When you want something else
xmllint --format in.xml does the same job at the command line and is installed on most Unix systems already; xmlstarlet fo --indent-tab gives more control over the indentation itself. Both handle files far larger than a page can hold in memory.
When the document needs to be compared, signed or stored canonically, formatting is the wrong operation entirely. Canonical XML — xmllint --c14n — produces the one normalised form that two equivalent documents both reduce to, which is what digital signatures over XML depend on. Pretty-printing a signed document breaks its signature, and that is the most expensive way to learn this.
Frequently asked questions
Is my XML stored anywhere?
No. There is no server call and no logging, and nothing is stored. You can disconnect from the internet after the page loads and it keeps working. That matters here more than it looks: the things people paste into an online formatter are API responses, config files and error payloads, and those routinely carry tokens, customer records and internal hostnames.
What survives formatting?
Comments, CDATA sections, processing instructions, the XML declaration and all namespace prefixes. Attribute order is kept as written. An element holding only text stays on one line, because breaking <title>Hello</title> across three lines is not prettier — and in a mixed-content document it would change what the text actually says.
Will indenting change what my XML means?
In an element that holds only other elements, no. But XML has no general rule that whitespace is insignificant — in mixed content, where text and elements sit side by side, added whitespace IS part of the text. That is why text-only elements are left on one line here rather than being split. If your document has real mixed content and whitespace matters to it, minifying is the safer operation.
Does it work with HTML?
Only if the HTML is well-formed XML — which most real HTML is not. Unclosed <br>, <img> and <li> tags, unquoted attributes and bare ampersands are all legal HTML and all invalid XML. The parser here is a strict XML parser, so it will report those as errors rather than guess. XHTML and SVG format perfectly.
What about SVG?
Yes — SVG is XML, and this is a good way to read a minified one. Paths, gradients and embedded styles all come through unchanged; only the whitespace between elements moves.
Is there a size limit?
Available memory, rather than a cap we impose. Documents of a few megabytes format instantly; very large ones are limited by how much can be held at once, not by anything on our side.
Good to know: Well-formedness only. The document is checked for balanced tags, correct nesting and legal characters, and re-indented — but a DTD or XSD is not fetched or applied, so a file can format cleanly and still be invalid against its schema. Namespaces are preserved exactly as written.
Put this tool on your website
Free for any blog, class page or help article. Paste one snippet and your visitors can use it right on your page.