Format and indent XML

XML formatting (also called XML pretty printing or XML indentation) consists of reorganising a compact or minified XML document into an indented, line-by-line structure. Well-formatted XML improves human readability, which is essential when reading a SOAP response, browsing an RSS feed or inspecting the content of a configuration file.

Concretely, XML is formatted for four main reasons:

• Debug: quickly spot an unclosed tag, a missing attribute or an inconsistent structure.
• Manual integration: cleanly copy a fragment into a configuration file without breaking existing indentation.
• Code review: comparing two versions of an XML document in a Git diff becomes readable when each tag is on its own line.
• Documentation and examples: a formatted XML is much more pedagogical in technical docs or a README.

XML remains pervasive in the software ecosystem. Here are the formats developers most often run through an XML formatter:

• SOAP responses: <soap:Envelope> envelopes returned by SOAP web services usually arrive minified.
• RSS and Atom feeds: to inspect or audit a syndication feed.
• Spring, Maven (pom.xml), Ant, Ivy configurations: Java build and dependency files.
• AndroidManifest.xml and other XML resources of an Android project.
• SVG files: a vector graphic exported from a design tool is often compressed onto a single line.
• E-commerce exports: Google Shopping product feeds, Magento, Shopify or PrestaShop exports.
• OOXML documents: .docx, .xlsx and .pptx files are ZIP archives containing XML files that often need to be inspected.
• XML sitemaps: the sitemap.xml served to search engines.

An XML formatter does not simply add whitespace at random. It performs two steps:

1. Parsing: the document is read then turned into a DOM tree (Document Object Model). This step also validates that the XML is well-formed (correctly nested tags, attributes in quotes, a single root element).
2. Indented serialisation: the DOM tree is re-emitted as text with line breaks between elements and indentation proportional to the depth in the tree.

This tree-based approach guarantees that the document's logical structure remains strictly identical: only non-significant whitespace between tags is modified. CDATA sections, comments and processing instructions are preserved. More advanced transformations (XSLT) or queries (XPath) actually operate on this same DOM tree.

The procedure is intentionally simple:

1. Paste your XML document into the text area, or upload an .xml file.
2. Submit the form: the document is parsed and indented automatically.
3. The formatted result appears in the output area. In case of a parsing error, a message indicates the nature and approximate position of the problem.
4. Copy the result with the dedicated button, or download it to embed directly in your project.

A few conventions to follow to produce clean and durable XML:

• Indentation: 2 or 4 spaces depending on your team's convention. Stay consistent across the whole project.
• Line breaks: one element per line, which makes Git diffs workable.
• CDATA sections: a good formatter fully preserves <![CDATA[ ... ]]> blocks without reindenting their content, which is treated as raw text.
• Encoding: always declare the encoding on the first line with <?xml version="1.0" encoding="UTF-8"?>. UTF-8 is the de facto standard.
• Attributes: if an element has many attributes, some teams put them on separate lines for readability; otherwise they stay on the same line as the opening tag.
• Comments: <!-- ... --> should be kept as is by the formatter.

Here is a concrete example of a compact XML beautified by the formatter.

Before (single line, unreadable):

<root><item id="1">val</item><item id="2">val2</item></root>

After (formatted with 2 spaces):

<?xml version="1.0" encoding="UTF-8"?>
<root>
  <item id="1">val</item>
  <item id="2">val2</item>
</root>

The logical structure is strictly identical: only the visual layout changes.

A larger XML document after formatting looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<root>
  <user id="12345">
    <name>John Doe</name>
    <email>johndoe@example.com</email>
    <address>
      <street>123 Main St</street>
      <city>Springfield</city>
      <state>IL</state>
      <postalCode>62704</postalCode>
      <country>USA</country>
    </address>
    <phoneNumbers>
      <phoneNumber type="home">555-1234</phoneNumber>
      <phoneNumber type="work">555-5678</phoneNumber>
    </phoneNumbers>
    <preferences>
      <newsletter>true</newsletter>
      <theme>dark</theme>
    </preferences>
    <lastLogin>2024-06-14T09:30:00Z</lastLogin>
  </user>
</root>