XML Formatter & Beautifier

What does an XML formatter do?

Machine-generated XML usually arrives as one endless line — fine for parsers, hopeless for humans. An XML formatter validates the markup, then rewrites it with one element per line and consistent indentation per nesting level, turning a wall of angle brackets into a document you can actually scan and review.

This formatter validates first and formats second: if the markup is broken you get the exact line and column of the first error rather than half-formatted output. Text content is kept inline with its element (collapsed content), which keeps documents compact without sacrificing readability.

Common XML formatting pitfalls

The errors that block formatting are almost always structural: a closing tag that doesn't match its opener, an unescaped & or < inside text content, attributes missing quotes, or content before the <?xml?> declaration. The validator points at each one with its position; fix and re-format.

Note that significant whitespace inside text nodes is preserved — formatting only touches the whitespace between elements, so your data never changes meaning. The XML validator is the same check without the reformatting step; an unescaped ampersand in text content is the usual culprit, and the XML escape tool shows what it should have been. To see what changed between two versions of a formatted document, use the XML diff.

Pretty-print XML

Pretty printing XML and formatting XML are the same operation under two names, and this page does both. Servers strip whitespace to save bytes, which leaves you debugging single-line documents where one missing tag is invisible; pretty printing restores the visual hierarchy — each nesting level indented, each element on its own line — so structure, omissions and duplication become obvious at a glance. Validation runs first, so a broken document yields a precise error position instead of half-printed output.

Which indentation should you pick? Two spaces keeps deeply nested enterprise schemas readable without horizontal scrolling, which is why it is the default here; four spaces reads better in documentation and slide decks; tabs let every reader choose their own width in their own editor. The choice is purely cosmetic — switch widths in the rail and re-print at any time without touching the data. Comments, CDATA sections, processing instructions and the XML prolog survive every setting unchanged, because the formatter works on the markup rather than parsing it into objects and re-serializing.

When you are finished reading and the document has to go back on the wire, XML Minify strips the whitespace out again, and the round trip is lossless in both directions. For exploring rather than reading, the XML Viewer renders the same document as a collapsible tree with sibling counts on every branch.

Pretty-print a decoded SAML or SOAP response

The single most common reason people arrive at an XML pretty printer is an authentication or integration failure: a SAML assertion that the service provider rejected, a SOAP fault whose text is buried in a 9,000-character envelope, or a WS-Security header that a partner insists is correct. In every case the document arrives compressed onto one line and often wrapped in another encoding on top of that.

The order of operations matters. A SAML response captured from a browser POST body is Base64 (and frequently URL-encoded first), so decode before you print: run the parameter through Base64 to XML, which decodes and validates in one step, and then pretty-print the result here. Once it is indented you can actually read the parts that decide whether the assertion is accepted — `<saml:Conditions NotBefore=… NotOnOrAfter=…>` for clock-skew rejections, `<saml:Audience>` for audience-restriction mismatches, `<saml:Subject>` and its `NameID` format, and the `<ds:Signature>` block with its `<ds:Reference URI=…>` pointing at the element the signature actually covers.

SOAP envelopes get the same treatment, with one caveat worth knowing: never re-indent an envelope you intend to send if it carries an XML signature. Digital signatures are computed over a canonicalized form of specific elements, and inserting whitespace inside a signed subtree invalidates the digest — the pretty-printed copy is for reading, not for replaying. For envelopes specifically, the SOAP formatter ships with a sample envelope and namespace-aware defaults; the WSDL formatter does the same for service definitions, where namespace prefixes do most of the work.