XML Beautifier

Developer Tools Data Format Converters

Paste minified or messy XML and the beautifier puts each element on its own line, indented by nesting level. For example, a one-line note element holding to and from children becomes four lines, with each child indented two spaces. Mismatched or unclosed tags are reported instead of silently formatted.

About this tool

API responses, SOAP envelopes, sitemaps and config files often arrive as one long line, which is hard to read and harder to diff. This beautifier re-indents the markup one node per line, keeps short text-only elements such as a title holding Dune on a single line, and leaves comments, CDATA sections, processing instructions and the DOCTYPE intact. While formatting it checks that every start tag has a matching end tag, so overlapping or unclosed elements are flagged with the tag name. It also reports the element count and the deepest nesting level. It does not validate against a DTD or XSD schema, and whitespace inside text nodes is collapsed to single spaces.

How to use it

Add the XML
Paste the markup into the box or open an .xml or .txt file from your device; it is read locally.
Pick an indent
Choose 2 spaces, 4 spaces or a tab per nesting level to match your project style.
Read the result
The formatted XML appears with element, depth and line counts; a nesting problem shows as an error naming the tag.
Copy it
Use Copy result to take the formatted markup back into your editor.

Examples

A one-line note document

XML to format: <note><to>Tove</to><from>Jani</from></note>
Indent: 2 spaces

Result Formatted XML: <note>
<to>Tove</to>
<from>Jani</from>
</note>
Elements: 3
Deepest nesting: 2
Output lines: 4
Comments: 0
Input characters: 43
Output characters: 50

Split the input into 8 nodes: tags, text, comments, CDATA and declarations.
Checked that every opening tag has a matching closing tag (3 elements, deepest nesting 2).
Wrote one node per line, indented by 2 spaces per level; short text-only elements stay on one line.

The root goes on its own line and each short child element keeps its text inline, indented two spaces.

Nested elements, 4-space indent

XML to format: <a><b x="1"/><c><d>z</d></c></a>
Indent: 4 spaces

Result Formatted XML: <a>
<b x="1"/>
<c>
<d>z</d>
</c>
</a>
Elements: 4
Deepest nesting: 3
Output lines: 6
Comments: 0
Input characters: 32
Output characters: 57

Split the input into 8 nodes: tags, text, comments, CDATA and declarations.
Checked that every opening tag has a matching closing tag (4 elements, deepest nesting 3).
Wrote one node per line, indented by 4 spaces per level; short text-only elements stay on one line.

The self-closing b element sits on one line, and d is indented two levels inside c.

How it is calculated

line indent = nesting depth × indent unit

nesting depth: number of elements still open when the node starts
indent unit: 2 spaces, 4 spaces or one tab, as chosen

The input is split into tags, text, comments, CDATA sections, processing instructions and declarations. Quoted attribute values are skipped while looking for the end of a tag, so a greater-than sign inside an attribute does not break it. A stack tracks open elements: each start tag pushes its name and each end tag must match the top, following the Element Type Match rule in XML 1.0. Each node is written on its own line at its depth, and an element holding only text is joined back onto one line.

When not to use it

To validate against a DTD or XSD schema, use a validating parser such as xmllint.
When whitespace inside text nodes is significant, because runs of spaces are collapsed.
For HTML that relies on unclosed tags like br or li, which XML rules reject.

Common mistakes

Pasting HTML with void tags such as br and expecting it to pass as XML.
Leaving a stray ampersand or less-than sign in text instead of escaping it as an entity.
Assuming formatted output is schema-valid just because the tags nest correctly.

Frequently asked questions

Does formatting change what the XML means?

Element names, attributes and order are untouched. Whitespace between tags and runs of spaces inside text are normalised, which matters only for documents where whitespace is significant, such as those using xml:space="preserve".

Why does it say a closing tag does not match?

XML requires elements to nest without overlapping. If element b opens inside element a, b must close before a does; closing a first breaks the Element Type Match rule of the XML 1.0 specification.

Are comments and CDATA sections kept?

Yes. Comments, CDATA blocks, the XML declaration and a DOCTYPE are each kept verbatim on their own line at the current indent level.

Can it format SVG or sitemap files?

Yes. SVG, RSS, Atom, sitemaps, Android layouts and Maven pom.xml files are all XML, so any well-formed one formats the same way.

Is my XML uploaded anywhere?

No. Parsing and indenting run in your browser, and an opened file is read locally without being sent to a server.

Which indent should I choose?

Two spaces keeps deep documents narrow and is common in web projects; four spaces matches many Java and .NET codebases; a tab lets each reader set the width in their editor.