How to use the XML formatter

Paste your XML into Input XML.
Choose an indent of 2 or 4 spaces and press Format XML to get one element per line.
Or press Minify XML to remove the line breaks and indentation between elements. Comments are kept unless you tick Remove comments when minifying.
Copy the result from Output. If the XML is not well-formed, an error appears instead.

Everything runs in your browser: the XML is read by the browser's own XML parser and written back out by the page, so it is never uploaded.

A minified file, formatted

This single line, typical of an API response or a generated configuration file:

<?xml version="1.0" encoding="UTF-8"?><config><!-- database settings --><database host="localhost" port="5432"><name>app</name><user>admin</user></database><features><feature enabled="true">search</feature><feature enabled="false"/></features></config>

becomes, with a 2-space indent:

<?xml version="1.0" encoding="UTF-8"?>
<config>
  <!-- database settings -->
  <database host="localhost" port="5432">
    <name>app</name>
    <user>admin</user>
  </database>
  <features>
    <feature enabled="true">search</feature>
    <feature enabled="false"/>
  </features>
</config>

The declaration, the comment, the attributes and their order are unchanged. Minifying the formatted version gives back the single line; with comments removed, the  part is dropped as well.

Well-formed is not the same as valid

Before formatting, the parser checks that the input is well-formed XML: one root element, every tag closed and properly nested, attribute values in quotes, and special characters escaped. It reports the first problem with its line and column. It does not validate the document against a DTD or an XML Schema (XSD), so a file can pass here and still be rejected by a system that expects particular elements.

The error text comes from the browser, so the wording differs between Chrome, Firefox and Safari. These are the messages Chrome gives for the most common mistakes:

Problem	Input	Chrome reports	Fix
Mismatched closing tag	`<order> <item>Book</itme> </order>`	Invalid XML at line 2, column 19: Unexpected closing tag: itme != item	Close each element with its exact name
Unescaped ampersand	`<company>Smith & Sons</company>`	Invalid XML at line 1, column 17: Unexpected token inside entity:	Write & as &
Two root elements	`<a/> <b/>`	Invalid XML at line 2, column 1: Unexpected token: <	Wrap everything in one root element
Undeclared namespace prefix	`<x:a>1</x:a>`	Invalid XML at line 1, column 5: Element x:a prefix is unbound	Declare it, e.g. xmlns:x="urn:example"
HTML entity	`<p>Price: 10</p>`	Invalid XML at line 1, column 15: Unexpected entity: nbsp	Use   instead
Unquoted attribute value	`<a id=1/>`	Invalid XML at line 1, column 7: Unexpected token: 1	Quote the value: id="1"

What formatting changes, and what it leaves alone

Whitespace is only added or removed inside element-only content: an element whose children are other elements, comments or processing instructions, separated by nothing or by whitespace that contains a line break. Everything else is written exactly as parsed:

Text and mixed content. A paragraph such as Press Save, then wait. stays on one line with its spaces, because changing whitespace inside it would change the text.
Spaces between tags on one line. In big deal the space could be content, so it is kept and the words are never joined.
xml:space="preserve". The content of such an element keeps its line breaks and indentation, until a descendant sets xml:space="default".
CDATA sections, comments and processing instructions are kept as they are, as are the XML declaration and the DOCTYPE, including an internal subset.
Names. Element and attribute names keep their case and namespace prefixes, and attributes keep their order.

A few details are normalised, because the parser does not record how they were written. Attribute values are always put in double quotes, an element with nothing inside is written as a self-closing tag, and character references become the characters they stand for, escaped again where XML requires it. For example:

<item id='7' note='say "hi"'><empty></empty><text>&lt;tag&gt; &amp; &#65;&#x42;</text></item>

becomes

<item id="7" note="say &quot;hi&quot;">
  <empty/>
  <text>&lt;tag&gt; &amp; AB</text>
</item>

Entities declared in the document's own DOCTYPE are replaced by their text in the same way. The result describes the same data as the input; only the notation differs.

Common pitfalls

HTML entities. XML only predefines &, <, >, " and '. Write a non-breaking space as  , not  , unless the DOCTYPE declares it. In the output, the reference becomes the non-breaking space character itself, which looks like an ordinary space.
Line breaks after minifying. Minify removes line breaks between elements only. A line break inside text or mixed content is part of the data and stays.
Anything before the declaration. <?xml ...?> must be the very first thing in the file; even a blank line before it makes the document invalid.
Expecting text to be reflowed. Long text and mixed content are not wrapped or re-indented. That is deliberate: the formatter never changes your data.

Frequently asked questions

Does the formatter validate against my XSD or DTD?

No. It only checks well-formedness. Use a schema validator when a document must follow a particular structure.

Why are some elements not indented?

They contain text next to child elements, or sit inside such an element, or inside xml:space="preserve". Adding line breaks there would add characters to the text.

Is it safe to paste configuration files?

The XML is processed in your browser and not sent to our servers. It is still good practice to remove passwords and keys before pasting them into any website.

Can it format HTML?

Only XHTML that is well-formed XML. Ordinary HTML usually has unclosed tags such as   and entities such as  , which the XML parser rejects.

XML Formatter