XML Beautifier
Paste XML to format, minify, or validate instantly.
Upload an XML or TXT file (max 5MB)
A Known Limitation: CDATA Sections and Beautify Don't Mix Well Here
This beautifier's indentation logic specifically recognizes comments (<!--...-->) and processing instructions (<?...?>) as special cases it should pass through without treating as ordinary tags — but it does not have a matching special case for CDATA sections (<![CDATA[...]]>). Practically, that means a CDATA block is parsed the same way as a regular opening tag: the formatter scans forward from < looking for the next >. Since the entire point of CDATA is to let you embed text containing literal < and > characters (a snippet of HTML or code, for example) without escaping them, a CDATA block whose payload contains those characters will get its structure split apart incorrectly by "Beautify." If your XML contains CDATA with embedded markup, beautify at your own risk and diff the output against the original, or minify instead — minification's regex-based whitespace collapsing is less likely to corrupt CDATA content than the tag-by-tag beautifier.
What "Validate" Actually Checks
Clicking "Validate" runs two passes: first, a same-page tag-counting check that confirms every opening tag has a matching closing tag by name (it will correctly flag </item> appearing without a matching <item>, for instance). Second, if your browser supports it, the text is handed to the native DOMParser for a real specification-compliant parse — this is what actually catches the rule that XML must have exactly one root element. Two sibling top-level elements (<a/><b/> with nothing wrapping them) will pass the simple tag-counting check (every tag is still self-closing and balanced) but will correctly fail at the DOMParser stage with a parser error, because well-formed XML requires a single top-level element containing everything else.
Self-closing tags (<br/>) are handled correctly by the indent logic — they don't increase the indent level the way a real opening tag does, since there's no corresponding closing tag to look for. If you're hand-writing XML and a beautify result looks over-indented, check for a tag you intended as self-closing that's missing its trailing slash.
Frequently Asked Questions
My XML has a CDATA block and "Beautify" mangled it — why?
The beautifier doesn't special-case CDATA the way it does comments, so a CDATA payload containing literal angle brackets can get split incorrectly. Use "Minify" instead for XML containing CDATA, or verify the beautified output carefully before relying on it.
Validate says my XML is invalid, but it looks fine to me — what's wrong?
A very common cause is multiple top-level elements: XML requires exactly one root element wrapping everything else. If you have two or more sibling elements at the outermost level, wrap them in a single parent element.
Does minifying remove comments permanently?
Yes — this tool's minify step strips <!--...--> comments along with collapsing whitespace, so keep an unminified copy if the comments contain information you need later.
Will beautifying change the actual data in my XML?
For ordinary elements, attributes, and text, no — only whitespace and line breaks are added. The one documented exception is CDATA sections containing angle brackets, as noted above, where the tag-based parser can misinterpret structure.
Does "Validate" check my XML against an XSD or DTD schema?
No — it checks that the XML is well-formed (proper nesting, one root element, valid syntax), not that it conforms to any particular schema. Schema validation against an XSD or DTD requires a separate tool that has that schema loaded.