XML Formatter — pretty-print or minify XML instantly

The XML formatter above takes minified, single-line, or inconsistently-indented XML and reformats it with clean, consistent indentation based on nesting depth — or, in Minify mode, strips it back down to the smallest possible size. It runs entirely in your browser using a real tokenizer, not a regular-expression guess, so it handles attributes, self-closing tags, comments, and text content correctly.

Arb Digital's developers deal with XML constantly in feed integrations, sitemap generation, and legacy system exports, and this formatter is the same logic we use internally, made free and public.

What This XML Formatter Does

You paste XML — however it's currently formatted, including a single unbroken line with no whitespace at all — and choose between Pretty-print, which adds newlines and indentation reflecting each element's depth in the tree, and Minify, which removes all non-essential whitespace between tags. The result panel reports how many elements were found, how deeply the document is nested, and the byte size of both the input and the formatted output, so you can immediately see how much the formatting changed the file size.

How to Use It

1. Paste your XML. It doesn't need to be indented already — the tool re-derives structure from the tags themselves.
2. Choose an indent size. Two spaces is the most common convention in modern XML tooling; four spaces or a tab are also available if that matches your project's style.
3. Pick Pretty-print or Minify depending on whether you're reading the document or shipping it somewhere size-sensitive.
4. Click Format XML and copy the result.

How the Formatter Works: Tokenizing, Not Guessing

A naive approach to "pretty-printing" XML — inserting a newline after every > character — breaks almost immediately, because it can't tell the difference between a tag boundary and a > that legitimately appears inside text content or an attribute value. This tool instead walks through the input character by character as a real tokenizer: it identifies where each tag starts and ends, distinguishes opening tags from closing tags from self-closing tags (like <price currency="USD"/>), and keeps text content attached to the element it belongs to rather than treating it as structure to indent.

Once the document is broken into that sequence of tokens, indentation becomes straightforward: every opening tag increases the nesting depth by one for whatever comes after it, every closing tag decreases it, and self-closing tags don't change the depth at all since nothing nests inside them. The formatter prints each tag on its own line prefixed with depth-many indent units, and keeps short text-only elements (like <author>Ava Chen</author>) compact on one line rather than needlessly splitting the text onto its own line, which keeps the output genuinely readable instead of just technically indented.

Well-Formed vs. Valid: Two Different Bars

XML has two separate correctness concepts that are easy to conflate. Well-formed means the document follows XML's basic syntax rules regardless of what it's about: every opening tag has a matching closing tag, tags are properly nested (no overlapping like <a><b></a></b>), there's exactly one root element, and attribute values are quoted. This formatter checks well-formedness as a side effect of tokenizing — if the tags don't nest correctly, it can't build a coherent indentation structure and will flag the problem.

Valid is a stricter, separate bar: a document is valid only if it also conforms to a specific schema or DTD (Document Type Definition) that defines which elements and attributes are allowed where, in what order, and how many times. A document can be perfectly well-formed XML and still be invalid against a particular schema — for example, well-formed XML with a <book> element missing a required <price> child that a bookstore's schema demands. This tool checks well-formedness and formats accordingly; validating against a specific schema is a separate, schema-aware step that depends entirely on which schema you're targeting. The W3C's XML 1.0 specification is the authoritative source for exactly what well-formedness requires.

Why Indentation Matters to Humans, Not Machines

It's worth being explicit about something that trips people up: whitespace between tags in minified XML and pretty-printed XML represents the exact same data to any correctly-written XML parser. A parser reading <a><b/></a> and one reading the same structure spread across three indented lines build an identical in-memory tree. Indentation is purely a readability aid for the humans debugging, reviewing, or writing the document by hand — which is exactly why it's safe to minify XML for transport (smaller payload, marginally faster parsing) and pretty-print it only when a person actually needs to read it, switching freely between the two without any risk of changing meaning.

XML vs. JSON for Data Interchange Today

XML used to be the default choice for web service payloads (SOAP APIs, RSS/Atom feeds, many enterprise systems still run on it), and it remains extremely common in specific domains — sitemaps, Office document formats, Android layout files, and countless legacy enterprise integrations. Its self-describing tag structure and mature schema/validation tooling (DTDs, XSD, XSLT for transformation) made it a strong fit for documents where structure needs to be verified rigorously and where mixed content — text interspersed with markup, like this article itself — is common.

JSON has become the default for most new web APIs because it maps directly onto data structures most programming languages already have (objects, arrays, strings, numbers) with far less syntactic overhead — no closing tags to repeat, no separate attribute-vs-element decision to make. But XML's verbosity is a genuine tradeoff, not just legacy baggage: repeating a tag name in both an opening and closing tag makes documents self-describing and resilient to partial reads, and its namespace system handles combining vocabularies from multiple sources more rigorously than anything JSON offers natively. For markup-heavy documents, config formats with strict validation needs, or systems that already speak XML, it remains the right tool.

A Worked Example: A Two-Book Catalog

The sample loaded into the tool above is a small, deliberately unindented catalog document with two <book> elements nested inside a single <catalog> root. Click Format XML in Pretty-print mode and you'll see each element land on its own line, indented two spaces deeper than its parent: <catalog> at depth zero, each <book> at depth one, and each book's children — author, title, price, description — at depth two. Notice that short elements like <author>Ava Chen</author> stay on a single line rather than being split across three; that's the formatter recognizing that an element whose only child is plain text doesn't need to be broken apart to be readable, which keeps the output compact without sacrificing clarity.

Switch Mode to Minify on that same input and the formatter strips every bit of the whitespace it just added back out, collapsing the document to a single line again — useful when you're about to paste that XML into a request body or a size-constrained field where every byte counts, and don't need it to be human-readable anymore.

Handling Attributes, Entities, and Self-Closing Tags

A correct XML formatter has to treat several constructs specially rather than just splitting on angle brackets. Attributes — the id="bk101" and currency="USD" pairs in the sample — live inside the opening tag itself and are preserved exactly as written, quotes included, without being reformatted or reordered. Entities like & (a literal ampersand) are left untouched as text content; the formatter never tries to decode or re-encode them, since doing so incorrectly is one of the easiest ways to silently corrupt a document that contains reserved characters. Self-closing tags like <br/> or <price currency="USD"/> are recognized as a single unit that doesn't open a new nesting level, unlike a full open-tag/close-tag pair — get this wrong and every element after a self-closing tag ends up indented one level too deep.

Common Mistakes to Avoid

• Unescaped special characters like a bare & or < inside text content — these must be written as entities (&, <) or the document isn't well-formed.
• Multiple root elements. XML requires exactly one top-level element wrapping everything else; two sibling elements at the top level make a document not well-formed.
• Mismatched or overlapping tags such as closing tags in the wrong order — nesting must be strictly hierarchical, never overlapping.
• Unquoted attribute values. Every attribute value must be wrapped in single or double quotes, unlike some looser markup languages.
• Assuming pretty-printed and minified XML differ semantically — they don't; only the whitespace changes, never the data a parser extracts.

Related Free Tools From Arb Digital

Working with JSON instead? Try the live JSON Formatter, the strict JSON Validator, or convert between formats with JSON to CSV and CSV to JSON. Also see the YAML to JSON Converter and the SQL Formatter. Browse everything in our free online tools hub.

Frequently Asked Questions