XML Formatter

Paste a wall of one-line XML and this tool hands you back something a person can actually read, nested by depth, one node per line. Then flip it: hit Minify and the same document collapses back to a single tight line, ready for the wire. Two directions, one box, and it all runs in your browser so a private config or an internal API payload never leaves your machine.

That last part matters more than people give it credit for. Plenty of the free XML tools quietly send your document off to a server to format it. Fine for a public RSS feed, not fine for a SOAP response full of account numbers or a web.xml out of an internal repo, and nothing is uploaded from this page. It loads files too, drop an .svg or a pom.xml into the box, click Open file, or paste.

1. Get your XML in. Paste it, drop an .xml file into the box, or click Open file. A minified one-liner, a config, an RSS feed, or a whole SOAP envelope from the <?xml ...?> line down, all fine.
2. Pick a direction. Format re-indents the document so you can read it. Minify strips the gaps and squeezes it back to one line. The output updates the instant you switch.
3. In Format, choose your indent. Two spaces, four spaces, or a tab. XML nests deep, so two spaces keeps a five-level SOAP body from running off the right edge.
4. In Minify, decide about comments. Leave them, or tick Remove comments to shed a few more bytes. Your CDATA and declaration stay put either way.
5. Copy or download. Grab the result with one click, or download it as an .xml file straight to your machine.
6. Watch for the red line. If the XML is broken, a tag that never closes, a mismatched pair, an unterminated CDATA, it points at the exact spot instead of spitting out garbage.

Hit Load sample to see it run on a squashed product catalog with a declaration, a comment, nested elements, a CDATA block full of angle brackets, and a self-closing tag, so you can watch what moves and what stays frozen in place.

Formatting and minifying are the same operation run backwards, so it never sat right that you'd need two separate sites for them. Format adds whitespace to make XML readable for a code review or a debugging session. Minify removes that whitespace to make the file smaller for transmission and storage. Both run through the same engine and the same well-formedness check, and only the output differs. And because both directions go through the same parser, the minifier inherits the formatter's care: it reads the whole tree first, confirms every tag matches, and only then collapses the whitespace. That is different from a find-and-replace that removes the newlines without checking the structure first.

This is where a lot of tools quietly wreck your file.

CDATA is untouchable. A block like <![CDATA[ if (x < y && a > b) ]]> exists precisely so its contents are NOT read as markup. A naive minifier that just strips whitespace, or worse, treats every < as the start of a tag, will happily mangle the code or markup inside your CDATA. This tool spots the <![CDATA[ opener, grabs the whole section through the matching ]]>, and copies it out character for character in both directions. Nothing inside ever gets squeezed, escaped, or re-read.

The declaration survives. <?xml version="1.0" encoding="UTF-8"?> isn't decoration. That encoding tells every downstream reader how to make sense of the bytes. Strip or rewrite it and a file full of accented characters can turn to mojibake. This tool keeps the declaration exactly as written, at the top, in both format and minify.

Whitespace is sometimes the data, and both directions leave that alone. In HTML the spaces between tags are usually throwaway. In XML they are not always, and there are two cases where they are plainly content. An element holding text and child tags together, <p>Hello <b>world</b> and more</p>, is using the gaps around the <b> as part of its sentence. And xml:space="preserve" is a standing instruction from whoever wrote the document, binding that element and everything under it. Both are copied out of your source character for character, in Format as much as in Minify, and the page lists every node it left alone with the reason for each, which is why a preserve block comes back ignoring the indent you picked.

There is a cost, and it is worth knowing before it surprises you. A document already written on one line, with single spaces between its tags, reads as content rather than as indentation, because a space typed between two tags on the same line usually is. That subtree gets left exactly as it is, so the saving on a file like that is small and the report says which nodes it was.

A formatter should change the layout of your document and nothing else. This one will not rename an element, reorder your attributes, strip a quote, escape or unescape anything, or add or delete a single tag. The document parses to the same tree it did before, all that moved is the shape. Short leaf elements like <name>Wireless Mouse</name> even stay on one line, because splitting three words across three rows adds clutter without adding clarity. A formatter that quietly rewrote your data instead of just its layout would not be safe to use.

One thing does move that is worth stating plainly rather than burying. Text that is the whole content of a leaf element gets tidied, so <price> 24.99 </price> comes back as <price>24.99</price>, which is what makes a squashed feed readable. An element whose entire contents are whitespace, like <gap> </gap>, keeps them, because there the whitespace is the value. If you need the spacing inside a leaf kept as written, put xml:space="preserve" on it and it will be.

One more thing worth naming, because it bites people coming from HTML: XML is case-sensitive. <Item> and <item> are two different elements, and a </Item> will not close an <item>. Because this tool matches every close to its open by exact name, a case mismatch shows up as a plain error, "<Item> is closed by </item>", instead of a silently broken tree you chase for an hour.

JSON won the API wars, so it's easy to assume XML died with the '00s. It didn't, it just moved into the plumbing: build configs like Maven's pom.xml and Android's AndroidManifest.xml, RSS and Atom feeds, SOAP responses out of banking and government systems, every .svg icon in your project, and the guts of a .docx (which is really a zip full of XML). When one of those lands in your lap as a single squashed line, this is the box you paste it into to read it. When you need to send one back out small, this is where you minify it.