How to Format and Validate XML in the Browser (Free)
Why XML formatting matters, what well-formed really means, and how to pretty-print, validate, and minify XML without installing anything.
XML has a reputation for being verbose, and the way it usually arrives makes it worse. An API returns a SOAP response as one 4,000-character line, or a config file gets saved with mangled indentation, and suddenly you’re squinting at a wall of angle brackets trying to find the one tag that’s out of place. The XML Formatter fixes the layout so you can actually read it.
What “well-formed” actually means
People say “valid XML” when they usually mean “well-formed” XML. The two aren’t the same. Well-formed is the low bar: every tag you open you also close, tags nest without crossing over each other, and attribute values sit inside quotes. Valid goes further — it means the document also matches a schema (a DTD or XSD) that says which elements are allowed where.
This tool checks the first thing. Write <a><b></a></b> and it stops, telling you it expected </b> but found </a>. That single check catches most of the errors that make a parser throw, because a crossed or missing tag is the classic reason XML won’t load.
Formatting vs minifying
Two buttons, opposite jobs.
Format takes compact XML and spreads it out: one element per line, nested children indented two spaces deeper than their parent. <note><to>Tove</to></note> becomes three readable lines. Text that sits directly inside a tag, like <to>Tove</to>, stays on one line instead of being blown apart, which keeps short values easy to scan.
Minify does the reverse. It strips the whitespace and line breaks between tags and hands back a single line. That’s what you want before pasting XML into a JSON string, a URL parameter, or anywhere the extra newlines would only add bytes. A pretty-printed 40 KB file often drops below 30 KB once the indentation is gone.
What it leaves alone
A formatter that cleans up too aggressively can quietly corrupt a document. This one refuses to touch three things:
- Anything inside quotes, so
<img src="a/b.png">keeps its slash and its spacing. - Comments.
<!-- TODO: check this -->is copied through byte for byte. - CDATA blocks. Content wrapped in
<![CDATA[ ... ]]>, often raw HTML or a code snippet, is passed straight through and never re-escaped.
Those three rules are the difference between reformatting a file and accidentally changing what it means.
It runs in your browser
There’s a practical reason to care where this runs. XML feeds carry things you might not want to paste into a random website: API keys in a config, customer records in an export, an internal service’s SOAP payload. Here the parsing happens in JavaScript on your own machine. Nothing is uploaded, nothing is logged. Load the page once, unplug from the network, and it still works.
A quick debugging trick
When an XML response won’t parse in my code, the fastest triage is to paste it into the formatter first. Either it formats cleanly, in which case the problem is my parsing and not the data, or it points at a specific mismatched tag and I’ve found the bug in ten seconds instead of reading raw text by eye.
Paste your XML into the XML Formatter and it will indent, validate, and minify on the spot, with nothing leaving your browser.