XML Formatter

What this tool does

This tool takes XML — minified, inconsistently indented, or generated by a tool that didn't bother to format it — and reformats it into clean, two-space-indented markup. It first checks that the document is well-formed; if it isn't, the exact position of the problem is reported instead of attempting a partial or garbled reformat. Attribute order, element order, comments, entity references (&, ©) and the XML declaration are preserved; only whitespace and line breaks change.

When you need it

• Reading a minified XML API response, SOAP payload or RSS feed that arrived as one unbroken line, where the actual structure is impossible to scan by eye.
• Reviewing a configuration file — an Android manifest, a Maven pom.xml, a .NET project file — before committing a hand-edit, to confirm the change didn't accidentally break the nesting.
• Cleaning up XML exported from a tool that writes everything on a single line or with inconsistent indentation, before pasting it into documentation or a code review.
• Comparing two XML documents more easily by eye, since consistent indentation makes structural differences visible without a dedicated diff tool.

How formatting works

The document is parsed into a tree, preserving attributes, element order and text content, then rebuilt with two spaces of indentation per nesting level. Because it goes through a real parse step rather than a text-based reflow, the result is always structurally identical to the input — reformatting never changes what the XML means, only how it's laid out on the page. Self-closing tags like <b/> are rewritten as an explicit opening and closing pair, such as <b></b>; both are equivalent XML, and the explicit form is generally easier to scan in a diff or a code review, since it visually matches every other element in the document.

What happens to whitespace

Whitespace-only text between tags is discarded and rebuilt from the indentation, so already-indented XML does not pick up blank lines. Leading and trailing spaces inside a text value are trimmed. For mixed content (text next to child elements, as in <p>Hello <b>bold</b> world</p>) the text pieces and the child element each end up on their own line, which changes the whitespace in the text; this is fine for data and configuration XML but not for XHTML or document markup where spacing is meaningful. A CDATA section is kept as CDATA, but an element whose only content is a CDATA section gains a line break after it. Processing instructions other than the declaration may lose their content (an xml-stylesheet instruction is kept, but one written as free text is reduced to its target name).

The XML declaration

If the input starts with an XML declaration (<?xml version="1.0" encoding="UTF-8"?>), it's kept on its own line above the formatted body, exactly as most XML tooling and API consumers expect it. A document without one is formatted the same way, just without that first line.

What happens with invalid XML

Before formatting, the document is checked for well-formedness — every tag must be properly opened, closed and nested, there must be exactly one root element, and every entity reference must be one of the five built-in ones, a numeric reference or a declared entity. If it isn't, the exact line, column and reason are shown (a mismatched closing tag naming which tag it expected and where the original was opened, for example) rather than attempting to force a reformat on broken input, which would only produce a confusing or misleading result.

Limits

Input is capped at 2 MB of XML text. This tool checks well-formedness only, not validity against a DTD or XSD schema — a document can be perfectly well-formed XML while still failing to match the specific structure a particular application or standard requires. For that level of checking, use a schema-aware validator built for your specific XML format.