Pretty-print XML with consistent indentation or minify it back down, with mismatched and unclosed tags reported by name instead of a silent failure. Runs entirely in your browser — your numbers never leave this device.
Paste XML and the formatter walks it tag by tag, tracking nesting depth as it goes: opening tags descend a level, closing tags climb back, and each line is indented by its depth. An element whose only content is text — <name>fig</name> — stays on one line, because splitting it across three would make real documents longer without making them clearer. Comments, the XML declaration, processing instructions and CDATA sections are carried through as they are. Minify runs the same walk and joins everything back with the inter-tag whitespace removed.
Because the walk maintains the stack of open tags, the formatter also checks well-formedness as it goes, and it reports problems by name: a closing tag that does not match the innermost open element is reported as the pair that clashed, with its line, and a document that ends with tags still open names the unclosed element. Be clear about the boundary of that check: well-formed is not the same as valid. This tool cannot know your schema, DTD or business rules, so it will happily format a well-formed invoice whose totals are wrong — structure is checked, meaning is yours.
The everyday traps are worth naming: XML is case-sensitive (<Name> and <name> are different elements), attribute values must be quoted, and a raw & or < inside text must be written as an entity — the HTML Entity tool covers those spellings. Everything runs in your browser; pasted documents are never uploaded.
Well-formed means the syntax rules hold: tags nest properly, attributes are quoted, there is one root element — the rules this formatter checks while it works. Valid means the document also obeys a specific schema or DTD: the right elements, in the right order, with the right types. No generic formatter can check validity, because it does not know your schema — be wary of any tool that claims otherwise.
Somewhere an opening tag never met its closing tag — the error names the element left open at the end of input, such as <a> in <a><b></b>. The usual causes are a self-closing tag typed as an opening one (<item> where <item/> was meant), a closing tag with a spelling or case difference (</Item> does not close <item>), or a document truncated in copying.
For most XML, no: whitespace between elements is presentation, and this formatter only re-indents element structure while keeping text-only elements on one line with their text untouched. The exception is documents where whitespace inside mixed content is significant (some publishing formats). If your format treats text spacing as content, minify a copy and compare before trusting it in production.
They pass through as structural lines at their nesting depth, unchanged: the <?xml …?> declaration, <!-- comments --> and <![CDATA[ … ]]> sections are carried verbatim. CDATA content is never re-indented or entity-encoded — leaving it byte-for-byte alone is the entire point of a CDATA section.
Yes. A namespaced tag such as <x:item xmlns:x="urn:example"> is treated as one element whose name includes its prefix, and opening and closing tags match when their full prefixed names match. The formatter does not resolve namespace URIs or check that prefixes are declared — that is schema-layer checking again.
No. Formatting and checking run entirely in your browser — documents never leave your device and are not stored or tracked.
More in Developer Tools · Browse all tools