XML Formatter & Validator

How to format XML

1. Paste your XML into the XML input box, or press Upload .xml to open a file. RSS/Atom feeds, SOAP responses, sitemaps, SVG and config files all work.
2. It is formatted as you type. Choose 2 spaces, 4 spaces or Tab under Indent.
3. Press Minify to strip whitespace instead, or Validate to check well-formedness without reformatting.
4. Press Copy or Download to take the result with you. Ctrl+Enter (Cmd+Enter on a Mac) re-runs the last action.

XML pretty print example

A one-line XML document is hard to scan:

<catalog><product id="BK-001"><name>Notes on the Analytical Engine</name><price>24.50</price></product></catalog>

Formatted with 2 spaces, each element gets its own line and nesting is indented:

<catalog>
  <product id="BK-001">
    <name>Notes on the Analytical Engine</name>
    <price>24.50</price>
  </product>
</catalog>

Attribute order (id="BK-001") is kept exactly as written, and elements holding only text, like <name> and <price>, stay on one line instead of being split further.

XML minify: strip it down for transport

Minifying removes every insignificant space, tab and line break between tags. The pretty printed example above shrinks from 130 to 113 characters:

<catalog><product id="BK-001"><name>Notes on the Analytical Engine</name><price>24.50</price></product></catalog>

Use minified XML for API payloads and anywhere size matters; use formatted XML for code review and debugging. Both parse to the same document.

How to validate XML (well-formedness)

Every time you type, paste or press Validate, the XML is checked with a hand-written parser built for this tool (not a browser DOM parser, so it stays consistent across browsers and reports a location even when the source has none). Valid XML shows a summary like "root <catalog>, 4 elements, nested 3 deep." Invalid XML shows:

• the line and column of the first problem;
• a plain-English explanation and, where it helps, what to write instead;
• a snippet of the lines around the error with the problem character highlighted, and a Show in input button that jumps to it.

This validator checks well-formedness (are the tags balanced and the syntax legal), not a schema: it will not tell you that an element is in the wrong place according to an XSD or DTD, only that the XML itself parses.

Why is my XML not well-formed? Common errors and fixes

These are the errors this validator reports for the mistakes we see most often:

• Unclosed tag: <order>↵ <item>Pen↵</order>
  line 3, column 3: Mismatched closing tag: expected </item> (opened at line 2) but found </order>.
• Mismatched closing tag: <order>↵ <item>Pen</item2>↵</order>
  line 2, column 14: Mismatched closing tag: expected </item> (opened at line 2) but found </item2>.
• Attribute value not quoted: <item id=42>Pen</item>
  line 1, column 10: The value of attribute "id" must be in quotes ("…" or '…').

Other frequent causes: a stray & that should be &, more than one root element, and a DOCTYPE that appears twice or after the root element.

What the formatter preserves: comments, CDATA, PIs, attribute order

Many "XML formatters" parse your document into a generic tree and rebuild it, which can silently reorder attributes, drop comments, or merge things that were kept separate. This tool works from the tokens of your original text instead, so it keeps:

• Comments (<!-- … -->), on their own line, wherever they appeared;
• CDATA sections (<![CDATA[ … ]]>), with their contents untouched and undecoded;
• Processing instructions like <?xml-stylesheet …?>, including the <?xml … ?> declaration;
• Attribute order and quote style (" or '), exactly as written;
• Mixed content — text next to inline elements — left exactly as written, rather than reflowed.

For example, this article mixes inline markup with an <em> tag, a comment, and a CDATA block holding code with a raw & and <:

<article lang="en">
  <!-- intro paragraph -->
  <p>Ada Lovelace wrote notes on <em>Babbage's</em> Analytical Engine.</p>
  <code><![CDATA[if (a < b) { return a & b; }]]></code>
</article>

Formatted, the comment and the <code> element each get their own line, but the sentence inside <p> is left exactly as written because it mixes text and an element:

<article lang="en">
  <!-- intro paragraph -->
  <p>Ada Lovelace wrote notes on <em>Babbage's</em> Analytical Engine.</p>
  <code><![CDATA[if (a < b) { return a & b; }]]></code>
</article>

XML formatter vs beautifier vs validator vs minifier

• XML validator: answers "is this well-formed XML?" and points to the first error.
• XML formatter or beautifier: rewrites well-formed XML with indentation, also called pretty print. It validates first, because broken XML cannot be reformatted.
• XML minifier: the reverse — removes whitespace to make the document smaller.
• None of these check the XML against a schema (XSD/DTD); they check the syntax only.

Security: DOCTYPE declarations and entities

XML parsers that expand entities can be tricked into reading local files (XXE) or into exponential memory blow-ups ("billion laughs"), both through a crafted <!DOCTYPE>. This formatter never expands any entity, standard or custom: it treats &, é and a custom &writer; the same way — as text to check for well-formedness and pass through unchanged. Here a DOCTYPE declares a custom entity, and it is echoed back exactly as written, never expanded:

<!DOCTYPE note [<!ENTITY writer "Ada">]>
<note><to>Babbage</to><from>&writer;</from></note>

<!DOCTYPE note [<!ENTITY writer "Ada">]>
<note>
  <to>Babbage</to>
  <from>&writer;</from>
</note>

And because everything runs in your browser, the XML never leaves your device in the first place.

More developer tools

• XML to JSON converter: turn XML into JSON, with attributes, repeated elements and CDATA handled.
• JSON formatter & validator: the same pretty print, minify and validate workflow for JSON.
• HTML viewer: paste HTML and see it rendered live in a sandboxed preview.

Frequently asked questions