XML Formatter

Paste or load XML, validate it with the browser parser, and get clean output with 2- or 4-space indent, CDATA kept and elements self-closed.

Parsing and formatting happen locally in your browser. Your XML never leaves your device.

Indent
—

How It Works

Pasting XML and pressing Format runs the browser's built-in DOMParser — the same synchronous parser the platform uses — over your text. If the result contains a parsererror node, the message and its line/column hint are surfaced instead of output. On success a recursive serializer walks the tree and rebuilds the document with your chosen indent, one element per line.

Why DOMParser fails (or parses) exactly where it does
DOMParser is strict and synchronous: well-formedness is all-or-nothing, so a single unclosed tag invalidates the whole file. The parsererror text it produces (including the position hint browsers append, like "Line Number: 12") is shown verbatim as the error line — the tool does not try to repair your XML, because silent repair changes documents.
Attribute order is preserved as-is
The DOM exposes attributes in document order, and the serializer writes them back in that same order. Nothing is sorted, deduplicated or normalized, so diffing two formatted files only shows real content changes — not a reshuffle of attributes.
CDATA and empty elements
CDATA sections are re-emitted whole, as raw text — they are the standard way to carry markup-like content and converting them to entities would be a rewrite, not a reformat. Elements with no children are written in self-closing form, so <row></row> becomes <row/>.

Frequently Asked Questions

Why does my file say it is not well-formed?

XML has a short list of strict rules and browsers reject the whole document when one is broken. The usual culprits: more than one root element, a tag closed with the wrong name or never closed, an unescaped & or < in text, mismatched case between opening and closing tags, or a stray character before the XML declaration. The error line points at the reported position so you can jump straight to the problem.

What is the difference between CDATA and escaping?

Both ways carry text that would otherwise break XML. Escaping replaces special characters with entities (&amp; for &, &lt; for <), while a CDATA section <![CDATA[ ... ]]> marks everything inside as raw text. This formatter preserves CDATA blocks verbatim — it does not convert them into escaped text or the other way around.

Do you resolve XML namespaces?

No. Namespace prefixes (like <soap:Envelope>) are preserved exactly as written — attributes, element names and all. The formatter only re-indents; it neither expands prefixes into URIs nor validates that a prefix is declared, so a namespace typo that parses will still print.

Will formatting change the meaning of my document?

Re-indenting adds whitespace between elements, which matters only if your parser treats whitespace inside elements as data (rare, mostly in schema-validated or mixed-content documents). Attribute order, entity handling and CDATA blocks are kept as-is, and an empty element prints as <tag/> exactly as XML defines it.

Is anything uploaded to a server?

No. Parsing and pretty-printing happen with the browser's built-in DOMParser and plain JavaScript. Your XML never leaves your device, and there is no network request attached to formatting.