XML Formatter

Turn a dense XML payload into something reviewable

An API trace often presents XML as one uninterrupted line. The data may be correct, yet reviewing a namespace-qualified branch or finding the parent of a failing element is unnecessarily difficult. This online XML formatter tokenizes common XML constructs, places nested elements on readable lines, and offers two-space, four-space, or tab indentation. The formatted document appears beside the source as you type.

The page also exposes three decisions that materially affect output: whether empty element pairs collapse, whether comments survive, and whether surrounding text whitespace is trimmed. Those controls make it useful for preparing a diagnostic sample or comparing tree structure, but they can also change lexical details. Always decide whether the job is presentation, data interchange, or byte-sensitive preservation before formatting.

Walk through one compact document

Paste this into Input XML:

<?xml version="1.0"?><catalog><!--draft--><book id="b1"><title>XML in Practice</title><summary><![CDATA[Use <tags> literally.]]></summary><note></note></book></catalog>

With two spaces, comments retained, text trimming enabled, and Collapse Empty Tags selected, the result is arranged as:

<?xml version="1.0"?>
<catalog>
  <!--draft-->
  <book id="b1">
    <title>XML in Practice</title>
    <summary>
      <![CDATA[Use <tags> literally.]]>
    </summary>
    <note />
  </book>
</catalog>

The formatter recognizes the XML declaration, comments, CDATA sections, opening tags, closing tags, self-closing tags, and text segments. A simple element containing single-line text stays on one line. More complex content receives nesting indentation.

Four controls, four different consequences

Indent

Choose 2 Spaces, 4 Spaces, or Tab. This affects only the generated layout. XML itself does not assign tree meaning to indentation in the way YAML does, although whitespace can still be character data depending on the document and consuming application.

Collapse Empty Tags

When an opening tag is immediately followed by its matching closing tag, the formatter can replace the pair with a self-closing form. Thus <note></note> becomes <note />. Under ordinary XML infoset processing these forms represent an empty element, but lexical consumers, signatures, or specialized pipelines may care about the exact serialization. Leave this disabled when preserving source form matters.

Keep Comments

Enabled by default, this includes <!-- ... --> tokens in output. Turning it off removes them from the generated text. Comments may carry operational instructions, provenance, or conditional-processing hints for people even when an XML application ignores them, so do not remove them casually.

Trim Whitespace

Enabled by default, this trims whitespace at the edges of text tokens. It makes element-only documents cleaner, but whitespace can be significant in mixed content, poetry, localization resources, and content using xml:space="preserve". The tool does not interpret xml:space; disable trimming when text spacing is part of the data.

The tag-stack check

After formatting, the tool walks recognized opening and closing tag tokens. Opening names are pushed onto a stack; each closing name must match the most recent opening name. A mismatch produces a message such as:

Mismatched tag: expected </item>, but got </order>

Remaining names produce an Unclosed tags error. Copy and Download are disabled while an error exists, though the generated formatting may still be visible. This check is valuable for ordinary nesting mistakes and supports names containing letters, digits, underscores, colons, periods, and hyphens.

It is not a validating XML processor. There is no DTD or XML Schema evaluation, entity declaration handling, namespace URI resolution, encoding verification, or complete XML grammar implementation. “Valid XML” in the output header means the tool’s token stack found no mismatch, not that the document is well-formed under every XML 1.0 production or valid against a vocabulary.

A formatter-led debugging routine

1. Preserve the original payload in your log or editor before making transformations.
2. Paste the smallest reproducible document into the formatter.
3. Start with comments retained, empty-tag collapsing off, and whitespace trimming off when fidelity matters.
4. Select an indentation style that makes parent-child depth obvious.
5. Read any mismatched or unclosed tag message and repair the source, not merely the output.
6. Re-enable trimming only if you know text-node boundaries are insignificant.
7. Collapse empty pairs only when the downstream system treats the serializations equivalently.
8. Copy the result or download formatted.xml after the error clears.
9. Parse the document with the target XML library and validate it against its DTD, XSD, RELAX NG schema, or application rules as appropriate.

Clear resets source, output, and error state. Copy writes the output pane to the clipboard. Download creates formatted.xml using the application/xml media type. All formatting reacts to input and option changes without a separate submit action.

Mixed content needs special care

Element-only XML is forgiving of added indentation when an application ignores whitespace-only nodes. Mixed content is not. Consider:

<p>Hello <em>careful</em> reader.</p>

Here text and an element participate in one sentence. Repositioning tokens or trimming boundaries can alter spaces around “careful.” This formatter uses straightforward token and whitespace rules rather than an XML-aware pretty-print policy for mixed content. Inspect prose-oriented XML, XHTML fragments, DocBook, DITA, and localization files closely.

CDATA also deserves precision. The formatter keeps a CDATA section intact as one token and indents it on a line. It does not parse markup-looking characters inside the section, which is appropriate, but it also does not validate every forbidden CDATA sequence. Likewise, processing instructions beginning with <? are retained and placed on their own line; their target-specific content is not interpreted.

Namespaces, declarations, and validation layers

A prefix such as xlink in <xlink:title> is accepted by the token name pattern and survives formatting. The tool does not check that the prefix is bound with xmlns:xlink, that a namespace declaration is in scope, or that an expanded name is permitted by a schema. Namespace well-formedness belongs to a conforming XML parser.

The XML declaration is recognized as a declaration token and retained. The tool does not transcode bytes or verify that a declared encoding matches the JavaScript string in the editor. Once XML has been pasted into a browser text area, it is already a character string rather than the original byte stream. Encoding investigations should therefore begin with the source bytes and transport headers, not a pasted copy.

When this free XML beautifier is the right instrument

Use it to inspect SOAP envelopes, RSS fragments, SVG markup, Maven snippets, integration-test fixtures, or an XML response copied from a console. It excels when the question is “which element contains this value?” or “where does nesting stop?” The side-by-side layout keeps the untouched input available while options reshape the output.

Avoid using a browser pretty printer as the only step before digitally signing XML, calculating canonical hashes, shipping whitespace-sensitive mixed content, or modifying documents that depend on entity declarations. XML Canonicalization (C14N) has explicit rules and is not the same as aesthetic indentation. A standards-aware library is necessary for those tasks.

Field notes

• An immediately adjacent empty pair can collapse; an element containing whitespace text may not follow the same path.
• Comments are either retained verbatim or omitted; they are not rewritten.
• Single-line simple text elements tend to remain compact.
• Text trimming changes token edges, not internal text spacing.
• The token matcher covers common syntax, not every legal XML construct.
• Error-free formatting is not XSD validation.

FAQ

Can the formatter use tabs?

Yes. The Indent menu offers tabs in addition to two and four spaces.

Does it preserve CDATA sections?

Recognized <![CDATA[...]]> sections are kept as indivisible tokens and emitted in the formatted output.

Will removing comments affect the source pane?

No. The input remains as entered. The Keep Comments setting only controls generated output.

Is <empty /> identical to <empty></empty>?

Both describe an empty element in ordinary XML parsing, but lexical form can matter to signatures or nonstandard consumers. The option should be used with that caveat.

Does the tool validate an XSD?

No. It performs a simple recognized-tag nesting check. It does not load schemas or assess element declarations, attributes, datatypes, or occurrence constraints.

Why did spaces in my sentence change?

Trim Whitespace removes leading and trailing whitespace from text tokens. Mixed-content documents can rely on those boundaries, so disable the option and review the result.

What is downloaded?

The Download button saves the current output as formatted.xml; it is unavailable when the stack check reports an error.