XML Formatter and Validator

What the XML formatter does

The formatter checks that your XML is well-formed by the rules of XML 1.0 (opens in a new tab), then lays it out with one element per line, or minifies it into as few characters as the content allows. Every problem it finds is listed with its line and column, not just the first one. It changes only the whitespace between elements: text, attribute values, comments and CDATA sections keep their content, so a SOAP message or an SVG still means the same thing afterwards.

How to format XML

Examples

<order id="7"><item sku="A1">2</item><item sku="B2">1</item><total>3</total></order>

<order id="7">
  <item sku="A1">2</item>
  <item sku="B2">1</item>
  <total>3</total>
</order>

<doc>
  <p>Use <code>x &lt; y</code>  here.</p>
  <script><![CDATA[if (a < b) go();]]></script>
</doc>

<doc><p>Use <code>x &lt; y</code>  here.</p><script><![CDATA[if (a < b) go();]]></script></doc>

<config><port>8080</config>

Line 1, column 19: </config> does not close <port>, which is open since line 1, column 9. Expected </port> here. (XML_MISMATCHED_TAG)

Well-formed is not the same as valid

Well-formed XML follows the grammar every XML document shares: one root element, every start tag closed by a matching end tag, attribute values in quotes, each attribute once per element, and & and < escaped in text. A parser refuses a document that breaks any of these rules, which is what this tool checks.

Valid XML is well-formed and also follows a schema, an XSD or a DTD, that says which elements may appear where. A <price> inside an <author> can be well-formed and still invalid. The formatter does not check schemas or namespaces: a namespace prefix that is never declared, like ord: without its xmlns:ord, passes here and fails in a namespace-aware parser.

Why some elements keep their own line breaks

XML has no rule for which whitespace matters, so the formatter changes it only where it cannot be part of the data. An element whose children are only other elements, comments and processing instructions gets one child per line. Every other element keeps its content exactly as written:

• a text-only element, like <title>Release notes</title>, stays on one line, and its text is never trimmed;
• mixed content, where text and elements sit side by side, as in <p>Hello <b>world</b>!</p>, keeps every space and line break, because indenting it would add words' worth of spaces to the text;
• an element with xml:space="preserve", the standard way to say that whitespace matters, keeps everything inside it, child elements included.

Minify follows the same rule from the other side: it removes only the whitespace between elements of element-only content, and never touches text.

What stays exactly as written

The XML declaration, processing instructions such as <?xml-stylesheet ...?>, comments, the DOCTYPE with its internal subset, and CDATA sections are copied unchanged. Attributes keep their order and their quotes, single or double. An empty element keeps its form: <br/>, <br /> and <br></br> each come out as they went in. When attributes stand on lines of their own, as in Android layout files, each one stays on its own line, indented one level under its tag.

Line breaks come out as LF. XML parsers turn CRLF into LF when they read a document anyway, so the content is the same.

Entities are never expanded

An entity reference like &e; is a placeholder that a parser replaces with text defined in the DOCTYPE. Expanding them is what makes two classic attacks possible. In a XXE attack (opens in a new tab), an entity defined as SYSTEM "file:///etc/passwd" makes the parser read a local file or a URL. In a "billion laughs" attack, entities defined by ten other entities, nine levels deep, grow a few hundred bytes into gigabytes.

This tool never expands entities and never reads anything outside the text you give it. The DOCTYPE is kept as text, a note says so, and every reference stays in the output as it was written. Without a DOCTYPE, only the five built-in entities, &, <, >, ' and ", are allowed; a   from HTML is an error, and   is the reference that works everywhere.

Encoding declarations and Latin-1 files

An XML file can name its encoding in the declaration, like <?xml version="1.0" encoding="ISO-8859-1"?>. When you open such a file, the formatter reads its bytes in that encoding, so accented letters come out right. Files with a UTF-8 or UTF-16 byte order mark are read by the mark. Pasted text is already text and needs no encoding.

The result is always UTF-8. If the declaration names another encoding, a note says so, and the declaration is left as it is: change it to encoding="UTF-8" before you save the result, or programs that trust the declaration will misread the letters.

Options

Common errors and fixes