What is an XML formatter?
XML that comes out of a web service, a config generator or a log file is written for machines: whole documents on a single line, nesting invisible, and a structural error — one mismatched tag — enough to make every downstream parser reject the lot. An XML formatter (also called a beautifier or pretty-printer) rewrites the document with consistent indentation: every nested element steps in by one level, siblings line up, and the tree becomes something you can read at a glance and diff without tears.
This one does a second job before it formats, the same discipline as this site's JSON and HTML tools: it checks well-formedness first. XML is unforgiving by design, so if the structure does not check out, you get the line and column of the first problem instead of a confidently reformatted mess.
How to use this tool
- Paste your XML into the box above (or press Load sample to see a worked example). You can also upload an .xml file or drop one onto the box — the file is read in your browser and never sent anywhere.
- Choose an indent — 2 spaces is the common default; 4 spaces and tabs are one click away.
- Press Format. If the document is well-formed you get the reformatted result and a line count; if it is not, you get the precise location of the first structural problem — fix that one and format again.
- Tick Auto-format as I type if you would rather not press the button: the result updates as you edit (very large inputs are still formatted on demand, to keep typing smooth). While the document is mid-edit and not yet well-formed, the message line tells you so and your last good result stays on screen.
- Use Copy result or Download result to take the formatted document with you. Your input above is never modified — the result is a separate copy.
Built for XML, not borrowed from HTML
This formatter has its own XML tokenizer — the document is never
piped through the HTML beautifier, because HTML's rules are wrong
for XML. The checker enforces XML's actual contract: every start
tag must be closed by its matching end tag, tag names are
case-sensitive (</A> does not close
<a>), there is exactly one root element, and
text lives inside it. Comments, CDATA sections, processing
instructions and a doctype (including one with an internal
subset) are recognised as the constructs they are: a
</tag> inside CDATA is data, not markup, and
is never "balanced" against anything.
What formatting never changes
Formatting here is a layout rewrite, never a data rewrite. Tag
names keep their spelling and case. Attributes are never
reordered, added, removed or split across lines, and their values
pass through byte-for-byte — entities included, never decoded.
An element whose only content is text stays on one line, its text
trimmed of the surrounding layout whitespace only. Mixed content —
text and elements side by side — puts each text chunk on its own
line, characters unaltered. The single respelling, stated openly:
an element with no content at all, written
<empty></empty>, is printed as
<empty/> — identical to every XML parser, and
the form every XML author writes by hand.
Examples
This compressed document:
<order id="1042"><customer>Ada</customer><items><item sku="A-1">2</item><item sku="B-7">1</item></items><note><![CDATA[Leave at <front> desk]]></note></order> formats into:
<order id="1042">
<customer>Ada</customer>
<items>
<item sku="A-1">2</item>
<item sku="B-7">1</item>
</items>
<note><![CDATA[Leave at <front> desk]]></note>
</order>
And this broken fragment — <name> closed by
</Name> — is reported as the case-sensitive
mismatch it is, instead of being reformatted into a guess:
<user><name>Ada</Name></user> Common XML mistakes this catches
- The case-mismatched close —
<Name>…</name>: fine in HTML, fatal in XML. - The HTML habit — leaving
<li>,<p>or<br>unclosed because HTML forgives it; XML does not. - Two documents in one file — a second root element where a log file or export glued two documents together.
- Text before the root — a stray character or an export banner ahead of the first tag.
- The unterminated comment or CDATA — everything after it is swallowed, and half the document "vanishes" without an error anywhere else.