XML Formatter

Check XML well-formedness and indent element-oriented XML without blindly inserting whitespace into mixed content or xml:space="preserve" subtrees.

Indentation

XML input0 characters

Formatted XML

Formatted XML will appear here...

Formatting can change whitespace and lexical spelling

Parsing happens in the browser with DOMParser, and DOM nodes are serialized with XMLSerializer. No request to an XML endpoint is made by the page code. Successful parsing proves well-formedness only; it does not prove schema validity, signature validity, trust, or safety in the server-side XML parser that will eventually consume the document.

Pretty indentation is safe only when the inserted whitespace is not data

Element-oriented XML is easy to read when nested elements start on their own lines. Mixed content is different. In Hello world!, inserting line breaks around  can change the text seen by an application.

Elements containing meaningful text, CDATA, whitespace-only content, or an inherited xml:space="preserve" instruction are therefore kept compact. The 2- or 4-space indentation is applied to structural, element-oriented subtrees instead of being forced through every node.

Well-formed does not mean valid for your application

XML well-formedness covers syntax such as matching start and end tags, proper nesting, quoted attributes, legal references, and one document element. A document can satisfy all of those rules and still violate an XSD, DTD validity constraint, or an application contract.

For example, <order><total>abc</total></order> is structurally plausible XML even if the receiving system requires total to be numeric. Formatting cannot answer that data-model question.

What survives the DOM round trip, and what may look different

Element and attribute names: the parsed DOM keeps namespace information, but serialization may alter an equivalent namespace prefix arrangement.
Comments and processing instructions: they remain nodes and are retained in structural output.
CDATA: a CDATA-containing element stays compact so indentation is not injected into its text.
XML declaration: an initial declaration is kept as written at the top, but its encoding label cannot verify the bytes that existed before the text was pasted into the browser.
Whitespace-only nodes: structural indentation can replace them when the subtree is treated as element-oriented.
Lexical details: quote style, empty-element spelling, attribute normalization, namespace prefixes, and entity spelling are not guaranteed to round-trip byte for byte.
DOCTYPE/entity spelling: parsing and serialization may normalize declarations or resolved entity content, so canonicalization and signature work need purpose-built XML tooling.

Element-only data and mixed content need different treatment

Element-oriented input

Input:
<users><user id="1"><name>Sneha</name></user></users>

Formatted:
<users>
  <user id="1">
    <name>Sneha</name>
  </user>
</users>

Mixed content

<p>Hello <strong>world</strong>!</p>

The sentence remains compact because new indentation between the text and  could become part of the content.

Most parser failures come from a small set of XML rules

Case matters: <Item></item> has mismatched element names.
Ampersands introduce references: a literal ampersand normally needs &.
Attributes need quoted values: write id="1", not id=1.
HTML boolean-attribute syntax does not carry over: XML cannot use a bare attribute such as disabled.
There is one document element: <a/> is not one well-formed XML document.
Only five entities are predefined by XML itself: &, <, >, ", and '. Other named entities need declarations.

A browser parse says nothing about how a backend handles external XML features

Different server-side parsers can enable external entities, schema loading, network access, or other features that are unrelated to pretty-printing. A document that formats cleanly here has not been tested for XXE resistance, expansion limits, schema trust, or the configuration of another runtime.

Keep resource limits and external-resource policy in the parser that will actually consume untrusted XML. Do not move a parsed DOM into an active HTML document and assume formatting has sanitized its elements or attributes.

The XML specification explains why whitespace needs care

The W3C XML 1.0 specification defines well-formedness and says processors pass non-markup characters to applications. It also defines xml:space as the signal for preserving whitespace intent. Browser-side parsing and serialization are documented by DOMParser.parseFromString() and XMLSerializer.serializeToString().

Where a formatter should stop

XSD, Relax NG, DTD validity, or application-schema checking.
Canonical XML and digital-signature byte-for-byte workflows.
Verifying an XML declaration's encoding against original file bytes.
Testing the security configuration of a backend XML parser.
Preserving every lexical choice, entity reference, prefix, or whitespace node exactly as typed.