XML Beautifier

What this XML beautifier does

Paste an XML document and the tool parses it, then writes it back out with consistent indentation and line breaks. It is a real parse-and-reserialise step, not a search-and-replace: the file must be well-formed XML before anything is formatted, and the output is generated from the parsed tree rather than from the original characters.

That approach gives predictable results. Elements that contain only other elements are placed on separate lines and indented by two spaces. Elements that contain text keep their content inline, because breaking text across lines would change what the document says. Empty elements are collapsed, the XML declaration is ensured, and attributes are written with double quotes.

Before and after

Input:

<root><p>Hello <b>bold</b> <i>it</i></p><empty></empty><c><![CDATA[a < b]]></c><!-- note --><x a="1" /></root>

Output:

<?xml version="1.0"?>
<root>
  <p>Hello <b>bold</b> <i>it</i></p>
  <empty/>
  <c><![CDATA[a < b]]></c>
  <!-- note -->
  <x a="1"/>
</root>

Note that the paragraph stays on one line. Mixed content, where text and elements share a parent, is deliberately left alone so the sentence still reads correctly.

What is preserved

What changes

• Indentation becomes two spaces per nesting level, replacing whatever the file used before.
• Line breaks are inserted between sibling elements where the parent holds only elements.
• The XML declaration is added if the input has none; an existing declaration is kept.
• Whitespace-only text nodes between elements are consumed and replaced by the new indentation, so the visual layout of the source is not preserved.
• Attribute quoting is normalised, so single-quoted attributes come back double-quoted.
• Entities and escapes are written in the canonical form produced by the XML writer, which may differ from how they were typed (for example a numeric escape for the same character).

None of these changes affect the document's meaning. They do affect diffs: running the formatter over a file in version control will rewrite every line that gained indentation.

Encoding and entities

The writer follows the encoding named in the XML declaration. A UTF-8 document stays UTF-8, and accented or non-Latin characters are normally written as themselves rather than as escapes. If the declared encoding cannot represent a character, the writer falls back to a numeric character reference so the document remains valid. A document that declares no encoding is treated as UTF-8 and gains the plain declaration line described above.

Entity references, written as an ampersand plus a name or number and a closing semicolon, are handled by the parser. The five predefined XML entities are always safe. A named entity defined only in an internal DTD subset depends on how the parser resolves it, and an entity defined in an external DTD is not fetched at all, which can leave a reference unresolved or fail the parse. If a document relies on a custom entity set, check the output before using it.

Namespaces are not rewritten. A default namespace stays default, prefixes stay as written, and no prefix is invented or removed. That matters for documents that mix vocabularies, such as an SVG fragment inside an XHTML wrapper.

Well-formedness is mandatory

The parser is strict. A tag that is not closed, an unquoted attribute, two root elements, a stray ampersand, a mismatched case in a tag name or an undeclared namespace prefix all cause the parse to fail. When that happens the tool returns an error and produces no output at all, not even a partially formatted document.

This is why HTML usually fails here. HTML tolerates unclosed <br> and <img> tags, optional end tags and bare ampersands; XML does not. If you need to tidy HTML, use an HTML formatter. If you need to turn HTML into XML, fix the structure first.

How to use the page

1. Check that the language selector reads XML. The editor is shared with the other code tools, and the selected language decides which service runs.
2. Paste the document into the Manual tab, or fetch a text file through the From URL tab.
3. Press Beautify. The formatted document appears in the output panel.
4. If an error appears instead, the input is not well-formed; fix the structure and try again. The error message is generic, so an XML validator with line numbers is more useful for large files.
5. Use Copy or Download to take the result as beautify-output.xml.
6. The footer badges report input and output character counts, which shows how much indentation was added.

Minify mode

The page also offers a Minify button. For XML it parses the document, disables pretty output and saves it without indentation, so the tree collapses onto fewer lines. It keeps the XML declaration, comments and CDATA sections; it is a whitespace removal pass, not a content compressor. If your goal is the smallest possible payload, a dedicated XML minifier that also strips comments will do more.

When it is useful

• API payloads. A SOAP or REST response pasted from a log becomes readable in one step.
• Configuration files. Maven, Ant, Spring, Android layout and many build files are XML and benefit from consistent indentation.
• SVG source. A one-line exported SVG becomes an editable tree. Be careful with <text> and <tspan>: the formatter preserves text content, but reindenting can still change whitespace between elements in ways that affect rendering.
• Code review. A formatted diff is easier to read than a single 4,000-character line.
• Well-formedness check. If the tool rejects the file, it is not valid XML, which is itself a useful signal.

Limits and caveats

Input is capped at 200,000 characters per request, and the conversion runs on the server. The service does not fetch external DTDs, so a document that depends on an external entity definition may fail or keep the reference unresolved. Very deep nesting can hit parser limits. The formatter does not validate against a schema, does not check business rules, does not fix broken markup and does not reorder attributes or elements. It also cannot preserve your original line wrapping, because wrapping is exactly what it recomputes.

Privacy

Your XML is sent to the server for parsing. Remove credentials, tokens, personal data and internal endpoint names before pasting, especially from SOAP envelopes and configuration files. The tool does not store a document history or return anything except the formatted text.

Common mistakes

• Pasting HTML. Optional end tags and bare ampersands fail the strict XML parser.
• Expecting comments to be removed in Beautify. They are preserved; Minify keeps them too.
• Expecting the original indentation to survive. Indentation is recalculated from scratch.
• Assuming a failure means the tool is broken. It usually means the document is not well-formed.
• Formatting a signed document. Any byte change invalidates XML signatures; format before signing, never after.
• Pasting secrets. The request leaves your browser.

Frequently Asked Questions