XML Formatter
Max 1 MB · Formats automatically as you type
Processed entirely in your browser — nothing is sent to a server.
XML (Extensible Markup Language) represents data as nested, named elements with optional attributes — the same basic shape JSON uses, but older, more verbose, and still the format of choice for SOAP APIs, RSS/Atom feeds, many legacy config files, and SVG markup. Like JSON, XML is trivial for a program to write and hard for a person to read once it’s been minified or generated without any indentation at all — a SOAP response or an exported config often arrives as a single unbroken line. This tool reverses that: it parses the XML and re-serializes it with consistent indentation, one element per line, without changing what the document actually says.
Well-formed vs. valid is a distinction this tool takes seriously rather than blurring. Well-formed means the XML’s own syntax is correct — every tag closed and properly nested, attribute values quoted, exactly one root element. Valid means the document additionally conforms to some external schema (a DTD or an XML Schema/XSD) that defines which elements and attributes are allowed where. This tool checks the first (using the browser’s own native DOMParser, the same well-formedness check every XML consumer performs before doing anything else) and makes no attempt at the second — a document can format here without error and still fail validation against whatever schema a specific API or format actually requires.
Formatting walks the parsed document and re-indents it with your choice of 2 spaces, 4 spaces, or a tab. Content that’s purely nested elements gets one child per line; content that mixes real text with elements — a sentence with an inline <b> tag in the middle of it, for instance — is left exactly as written, with no whitespace inserted that would change what the text says. Comments, processing instructions, CDATA sections, and an XML declaration at the very top (if present) are all preserved. Minifying does the reverse: it strips every bit of formatting whitespace back out, collapsing the document to its smallest form, which is what you want before embedding XML in a URL or storing it where every byte counts rather than reading it.
If the input isn’t well-formed, the tool shows the parser’s own error message — typically with a line and column — instead of a blank output, so you can find and fix the specific broken tag rather than guessing.
Examples
- Reading a SOAP response — paste a minified <code><soap:Envelope></code> body straight from a network capture and see its nested <code>Header</code>/<code>Body</code> structure, attributes, and namespace prefixes laid out on indented lines instead of one unbroken line.
- Cleaning up an RSS/Atom feed — format a feed's raw XML to check that <code><item></code> entries, dates, and enclosure attributes are structured the way you expect before publishing or debugging a feed reader issue.
- Inspecting or minifying SVG markup — pretty-print a minified SVG you found in a design export to read its <code>path</code>/<code>g</code> nesting, or switch to Minify mode to strip whitespace back out before inlining it in HTML. For the equivalent tool when the payload is JSON instead of XML, see JSON Formatter.
Frequently asked questions
Is my XML sent anywhere?
DOMParser API — no library, no network request. This matters here specifically: a real XML payload routinely carries a SOAP Authorization header, an API token, or a config secret, and none of it ever leaves your device.Does this validate my XML against a schema (XSD/DTD)?
What happens to self-closing tags, like <code><br/></code>?
<tag/>) on output, regardless of whether you originally wrote it as <tag/> or <tag></tag>. The browser's parser doesn't preserve which form you used — both produce an identical, indistinguishable empty element once parsed — so there's no original form left to round-trip. This is a normalization, not data loss: the two forms are equivalent in XML, and self-closing is simply the one form this tool always writes back out.Does it support XML namespaces, like <code>xmlns:soap</code>?
<soap:Envelope>, soap:encodingStyle="...") and the xmlns:* declarations that define them are preserved exactly as written — they're ordinary attributes and tag names as far as formatting is concerned, so nothing about them needs special handling to survive a round trip.What happens to CDATA sections?
<![CDATA[...]]> section is preserved exactly, including any <, >, or & characters inside it — that's the entire purpose of CDATA, to hold text a parser shouldn't try to interpret as markup. It's never merged with surrounding text or re-escaped, and its position relative to any sibling text is left undisturbed rather than being pushed onto its own indented line.