XML Formatter, Minifier & Validator
Indent messy XML, minify it for transport, and check well-formedness with errors reported by line and column.
Your Data Never Leaves Your Device
Every tool runs entirely in your browser. Nothing you type is uploaded, stored, or logged on our servers.
The XML Formatter takes raw or minified XML and gives you clean, indented output — or strips the whitespace back out when you need it small for transport. Choose 2 spaces, 4 spaces, or tabs, and optionally put each attribute on its own line, which makes wide tags in Android layouts and SVG far easier to read and diff.
Well-formedness is checked by the browser's own XML parser, so errors come back with the exact line and column where parsing failed rather than a vague "invalid XML". Comments, CDATA sections, processing instructions, and the <?xml ... ?> declaration are all preserved through both directions — nothing is quietly dropped.
Namespaced documents work as-is: SOAP envelopes, RSS and Atom feeds, Maven POMs, and SVG all format with their prefixes intact. Everything runs client-side, so payloads carrying internal hostnames or credentials never leave your machine. Note that this validates well-formedness only — checking a document against an XSD schema or DTD is a different job and is not performed here.
FAQ
It re-indents XML so the nesting is visible. Beautifying adds line breaks and indentation to make a document readable; minifying strips that whitespace back out to make it smaller for transport. Neither changes the data — only the whitespace between elements.
No. It checks well-formedness — that tags are balanced, properly nested, and correctly quoted — using the browser's own XML parser. Validation against an XSD schema or DTD, which checks that the structure matches a contract, is out of scope here.
The usual causes are an unclosed or mismatched tag, an unescaped & or < inside text content (they must be & and <), a missing quote around an attribute value, or more than one root element. The error message reports the line and column where the parser gave up.
Yes. Comments, CDATA sections, processing instructions, and the <?xml ... ?> declaration all survive both beautifying and minifying — they are re-emitted rather than dropped.
Yes. Namespaced documents such as SOAP envelopes, RSS and Atom feeds, SVG files, Maven POMs, and Android layouts all format normally — namespace prefixes are preserved exactly as written.
Elements carrying several attributes get each attribute on its own line, which makes wide tags — common in Android layouts and SVG — far easier to read and produces cleaner diffs in version control.
No. Parsing, formatting, and validation all happen in your browser, so configuration files, SOAP payloads, and anything containing internal hostnames or credentials stay on your machine.
Yes. Whitespace between elements is insignificant in XML, so removing it produces a document parsers treat identically. Whitespace inside text content and CDATA is left untouched, since that is significant.