Format & validate XML online

An XML formatter that pinpoints the broken tag

Paste your XML and Indentio re-indents it cleanly while keeping comments, CDATA, and declarations intact. If a tag is unclosed or mismatched, or an ampersand isn’t escaped, the exact line and column is underlined in red with a clear explanation — no more scanning thousands of lines by hand.

XML failures are unusually frustrating because the parser reports where it gave up, not where you made the mistake. Forget a </item> on line 40 and a strict parser happily reads on until the document ends, then complains about line 4,000. Seeing the structure properly indented is often enough on its own to make the missing tag obvious — the nesting simply stops lining up.

How to use it

1. Paste or upload your XML (or a .svg, .xsd, .rss…), or load the Sample.
2. Well-formedness errors are underlined live — hover for the reason and a fix hint.
3. Click Format to beautify or Minify to compact.
4. Open Tree view to inspect elements and attributes, then Copy or Download.

Whitespace in XML is not always insignificant

This is the one genuine difference between formatting XML and formatting JSON, and it catches people out. In JSON, whitespace between tokens carries no meaning at all, so a formatter can rearrange it freely. In XML, the characters between tags are the element’s text content. Re-indenting can therefore change data:

<!-- Before: the element contains exactly "Ada Lovelace" -->
<name>Ada Lovelace</name>

<!-- Naively re-indented: now contains "\n  Ada Lovelace\n" -->
<name>
  Ada Lovelace
</name>

Indentio only introduces line breaks between element-only content — elements whose children are other elements — and leaves elements containing text exactly as they are. It also honours xml:space="preserve", the attribute the XML specification defines for telling processors that whitespace inside an element is meaningful. If you have a document where indentation genuinely matters and it is not marked, add that attribute before formatting.

The awkward case is mixed content — an element holding both text and child elements, like <p>See <b>this</b> page</p>, common in DocBook, XHTML, and RSS descriptions. There is no way to re-indent mixed content without altering the text, so it is left on a single line. That is deliberate, not a limitation.

What survives a formatting pass

Formatting is a parse-and-re-emit cycle, so it is worth knowing what comes back unchanged:

Minifying XML

Minify removes the whitespace between elements, which is the mirror image of formatting and carries the same caveat: it is safe for element-only content and it is applied conservatively everywhere else. Text content, CDATA, and comments are never stripped.

XML minification matters more than JSON minification, because XML is verbose by design — every element name is written twice. On a large SOAP envelope or an RSS feed, removing indentation can cut 20–30% of the bytes. As with JSON, though, most of that saving overlaps with what gzip would have compressed away anyway, so treat it as a readability decision first and a bandwidth decision second.

Formatting specific XML dialects

Everything below is XML, so all of it formats and validates here — but each has its own characteristic failure:

• SVG — exported files often arrive as one enormous line with thousands of path coordinates. Formatting makes the layer structure readable. Watch for <text> elements, whose whitespace is significant.
• RSS and Atom feeds — the usual break is an unescaped & in a URL inside <link> or a raw HTML snippet in <description> that should have been wrapped in CDATA.
• Maven pom.xml — deep, element-only, and formats perfectly. A missing </dependency> is the classic error and shows up immediately in the indentation.
• XML sitemaps — query strings full of ampersands are the number one cause of a sitemap that Search Console refuses to read.
• XSD, WSDL, and SOAP — heavily namespaced. An undeclared prefix such as xs: is a well-formedness error, not a schema error, so it is caught here.
• Android layouts and .NET .config files — attribute-heavy, so formatting mostly helps by revealing nesting depth.

Common XML errors it catches

• Mismatched tags — <a><b>…</a> reports where the nesting breaks.
• Unclosed elements — an element opened but never closed.
• Unescaped characters — a literal & must be written as &.
• Duplicate attributes on a single element.
• Unquoted attribute values — legal in HTML, never in XML.
• Multiple root elements — an XML document needs exactly one root.
• Content before the declaration — a stray space, blank line, or byte-order mark ahead of <?xml produces “content is not allowed in prolog”.
• Double hyphens inside a comment — -- is forbidden within <!-- … -->.

Well-formed vs. valid XML

These two words are used interchangeably in conversation and mean different things in the specification. Well-formed means the document obeys XML’s syntax: one root, correctly nested and closed tags, escaped special characters, quoted attribute values. That is a property of the markup alone, and it is what this tool checks — it is also what you need 99% of the time, because a document that is not well-formed cannot be parsed at all.

Valid is a stronger claim: the document is well-formed and conforms to a specific schema — a DTD, XSD, or RELAX NG grammar — that says which elements may appear, in what order, and with which attributes. A document can be perfectly well-formed and still invalid against its schema, for example by putting <price> where the schema requires <cost>. Schema validation needs the schema file itself and is on our roadmap.

Encoding, and the invisible character that breaks everything

An XML declaration can name an encoding — <?xml version="1.0" encoding="UTF-8"?> — and when it does, the declaration must tell the truth. A file saved as Windows-1252 but declaring UTF-8 will parse until the first accented character and then fail with an invalid-byte error that points at a character which looks perfectly normal in your editor.

The related trap is the byte-order mark, three invisible bytes some Windows editors write at the start of a UTF-8 file. Many parsers accept it; some report “content is not allowed in prolog” and give you no hint that the offending content is a character you cannot see. If a document looks flawless and still refuses to parse at line 1, column 1, re-save it as “UTF-8 without BOM”.

Go deeper