Browser-only · Explicit layout · No sign-up
Format compressed XML into a readable hierarchy with two spaces, four spaces, or tabs and choose LF or CRLF output. The document stays in this browser tab.
<catalog>
<product id="p-104">
<name>Trail Bottle</name>
<stock>18</stock>
</product>
</catalog>Readable nestingReview before replacing source
Pretty-print in a local worker
The formatter checks XML 1.0 document structure, then replaces eligible whitespace between or around markup while preserving raw markup tokens. A DOCTYPE is handled as opaque source, so its DTD grammar is not checked. No referenced resource is fetched and no schema validity is proved.
Loading the private XML formatter…
Enable JavaScript to format XML locally. The workflow and limitations below remain available without it.
A reviewable three-step workflow
Treat pretty printing as a source transformation that deserves a diff, even when the intended change is indentation.
Use a complete document with one root element. The tool rejects malformed markup, custom entity declarations, undefined named references, excessive nesting, and inputs above the page limit.
Select two spaces, four spaces, or tabs, then choose Unix-style LF or Windows-style CRLF separators. These controls apply to newly inserted structural whitespace, not verbatim preserved subtrees.
Copy or download the formatted XML, compare it with the original, and run the consuming system's parser, schema checks, signature checks, and tests where applicable. Browser download is disabled when the declaration names a non-UTF-8 encoding.
More precise than “add whitespace”
An XML formatter makes element nesting easier to scan by placing structural nodes on lines and indenting descendants. It can clarify a compact configuration file, SOAP envelope, Maven document, SVG source, syndication feed, or test fixture. Formatting does not explain whether the element names are correct for that vocabulary.
This implementation preserves each raw tag and retained content token. Attribute order and quote style, self-closing spelling, supported entity-reference spellings, XML declarations, comments, CDATA sections, processing instructions, namespace prefixes, mixed-content subtrees, and inherited xml:space="preserve" regions remain verbatim. The formatter only replaces eligible whitespace between or around markup; this includes document-edge whitespace and inter-tag whitespace in regions that look element-only.
That narrow change still deserves a diff. Inter-tag whitespace becomes a text node in the XML data model, and a consumer can observe it even in a vocabulary that normally treats it as indentation. Byte comparisons, digests, canonicalization inputs, snapshots, and signatures can also change when structural whitespace changes.
Cryptographic XML signatures and canonicalization are especially sensitive. Pretty printing is not XML Canonicalization and does not preserve or verify a signature. If a signed document must remain verifiable, follow the signature profile and canonicalization algorithm used by the sender instead of reformatting the signed bytes.
Whitespace may be data
xml:space need special careNot every line break is safely decorative. Text-bearing XML can assign meaning to spaces between child elements.
A document whose parent elements contain only other elements is usually the clearest candidate for indentation. Even when every markup token stays exact, signatures and downstream byte comparisons can make newly inserted whitespace relevant.
In <p>Read <em>this</em> now</p>, text occurs before and after a child element. Inserting visual line breaks can change the character data observed by an application.
xml:space="preserve"The reserved xml:space attribute communicates whitespace-handling intent. A careful formatter should avoid inventing indentation within a preserved subtree, and a reviewer should confirm the consuming application behaves as expected.
CDATA provides a source spelling for character data, while entity references provide another. This formatter keeps those raw spellings verbatim. Custom entity declarations and undefined named references are rejected because their replacement text is not expanded.
Document text remains local
XML often contains account identifiers, internal endpoints, build coordinates, message payloads, or operational metadata. When you press the format button, LiveParse creates a disposable Web Worker in this tab. The document is not posted to a formatter API, placed in the URL, or written to browser storage by the tool.
Input is limited to 200,000 UTF-16 code units and the page warns above 100,000; an astral Unicode symbol uses two units. The formatting operation is stopped after two seconds after the worker is ready, while worker loading has a separate twelve-second limit. Changing the source or an option terminates the current worker, preventing an older result from replacing newer input.
The XML parser never fetches external resources. A DOCTYPE is preserved as opaque source and is not validated; custom entity declarations and undefined named references are rejected. This boundary does not control browser extensions, clipboard managers, downloaded files, device backups, screen sharing, or other local software. Redact secrets and follow your organization's data-handling policy.
Use the well-formedness checker for syntax diagnostics or the tree viewer for a searchable text outline. Neither tool validates an XSD.
Open the XML Validator →Before committing formatted output
Questions answered
No. Formatting runs in a disposable Web Worker in the current browser tab. LiveParse does not send the source to a formatting service or put it in the URL.
It preserves raw tags, attribute order and quotes, self-closing spelling, supported entity-reference spellings, declarations, comments, CDATA, processing instructions, mixed-content subtrees, and inherited xml:space="preserve" regions. It changes eligible whitespace between or around markup, including document-edge whitespace, so review a diff before replacing source.
No. Pretty printing changes presentation. It does not evaluate DTD, XSD, Relax NG, Schematron, signatures, namespace policies, or application constraints. Read the well-formed versus valid XML guide.
Yes. Choose two spaces, four spaces, or tabs for indentation and LF or CRLF for newly inserted structural separators. Raw mixed-content and preserved-space subtrees keep their original text. The browser creates text downloads as UTF-8, so download is disabled if the preserved XML declaration names another encoding; copy into an encoding-aware editor instead.
No. External resources are never fetched. A DOCTYPE can be preserved as opaque source, but its grammar is not validated. Custom entity declarations and undefined named entity references are rejected.
Do not assume so. XML signatures use specified canonicalization and transformation rules. A general pretty printer is not a canonicalizer or signature verifier, and changed inter-tag whitespace can change signed data. Follow the signature profile and verify independently.