About this tool
Beautify compressed XML, copied feed items, SOAP payloads, sitemap fragments, and integration responses so nested elements and attributes are easier to review.
XML Formatter re-indents a well-formed XML document so nested elements, attributes, CDATA sections, and processing instructions are easy to read, then reparses its own output and compares the two trees to make sure nothing structural changed. It runs entirely in the browser using the native DOM parser, which means malformed input produces a parser error rather than a half-formatted result. Input is capped at 2,000,000 characters, 200,000 nodes, 100,000 elements, 200,000 attributes, and 128 nesting levels, and the formatted output may not exceed 5,000,000 characters. DOCTYPE and entity declarations are rejected outright. The result can be copied or downloaded as an XML file, and the header shows element and attribute counts for the document.
- Preserves namespaces, attributes, CDATA, processing instructions, mixed-content spacing, and xml:space preserve subtrees while re-indenting element-only content.
- Rejects malformed XML and DOCTYPE declarations and bounds input, output, nodes, elements, attributes, and nesting depth.
- Reparses and structurally compares every result before local copy or XML download is enabled.
How to use XML Formatter
The page opens with a small sample feed in the XML input box; replace it with your own document. Choose Indentation of 2 spaces, 4 spaces, or Tab, and pick LF or CRLF line endings to match the system that will read the file. Two checkboxes set policy: Preserve comments is on by default and can be turned off to strip every comment, and Expand empty elements rewrites self-closing tags like <item/> as <item></item> for parsers that expect that form. Click Format XML. If parsing fails, the error message names the problem; otherwise the Formatted XML panel appears with a Structurally verified badge, element and attribute counts, and any warnings. Use the copy control or the XML download button to save the result.
When this tool is useful
- An integration engineer reading a SOAP response that arrived as one long line and needs to find a nested fault element.
- An SEO specialist inspecting a sitemap fragment to confirm every url entry has the loc and lastmod children in the right order.
- A developer diffing two versions of a Maven pom.xml or Android manifest after normalizing indentation and line endings.
- A content editor checking an RSS or Atom feed item with CDATA descriptions before it is submitted to a syndication partner.
- A support analyst tidying a configuration export attached to a ticket so a colleague can review it without a desktop IDE.
Practical tips
- Mixed content, where text and child elements share a parent, is left compact on purpose. Reflowing it would insert whitespace that changes the text, so those lines stay long.
- Subtrees marked xml:space="preserve" are also left untouched; if you need them reflowed, that attribute is the reason they are not.
- Documents with a DOCTYPE are refused. Strip the declaration first if you only need the body formatted, and keep it in your original file.
- Turning off Preserve comments is a good way to produce a clean copy for a partner, but do it on a copy, since the removal is not reversible here.
- Choose CRLF only when the target is a Windows tool that insists on it; most parsers, build tools, and version control systems are happier with LF.
Examples you can test
Load an example, compare the result with the expected output, then replace it with your own input.
Expand a one-line feed
Example input
<feed><entry id="1"><title>Launch</title><status>published</status></entry></feed>
Expected output
<feed>
<entry id="1">
<title>Launch</title>
<status>published</status>
</entry>
</feed>Attributes stay on the opening tag and element-only children move to their own indented lines, which is the case most API and CMS exports fall into.
Normalize empty elements for a strict consumer
Example input
<config><cache/><debug enabled="false"/></config> with Expand empty elements checked
Expected output
<config> <cache></cache> <debug enabled="false"></debug> </config>
Both forms mean the same thing in XML, but some older parsers and templating systems only handle the explicit open-and-close style.
Validation checklist
- Fix the reported parser error before relying on any formatted output.
- Check the element and attribute counts against what you expect from the source.
- Confirm the indentation and line-ending choice match the system that will read the file.
- Look for a comments-removed warning if comments carried meaning in the original.
- Keep the unformatted original when the XML is part of an audit trail or support case.