XML Formatter
Indenting happens after the parse, not before
A formatter has to build a tree before it can print one. So when this tool returns a message instead of tidy output, the document is not merely untidy: it is not well-formed, and any conforming parser rejects it too. Fixing what it reports is the work; the indentation follows.
A well-formedness error is fatal: the parser reports the first one and stops. Correcting one unclosed tag and running it again often surfaces a second problem further down. That is expected.
The five mistakes behind most failures
- Case mismatch. XML is case sensitive.
<Item>closes with</Item>and nothing else, prefix included. HTML forgives the mix, which is why the habit carries over. - Unclosed or crossed tags. Every element needs a close tag or a self-closing form such as
<br/>, and nesting cannot overlap.<a><b></a></b>is never legal. - Unescaped characters. In text and in attribute values,
&must be written&and<as<. A URL with a query string, pasted straight in, is the usual culprit.>is legal alone and only has to be escaped where it would form]]>. - Two root elements. One outermost element encloses everything. Concatenated API responses and log fragments fail here even though each piece is fine alone.
- Something ahead of the declaration.
<?xml version="1.0"?>is optional in XML 1.0, but if it is there it must be the very first thing in the file: no blank line, no comment, no leading space. A UTF-8 byte order mark is allowed by the spec as an encoding signature, yet it is the commonest trigger for prolog errors. Save without one.
Two smaller ones: attribute values must be quoted, single or double, and the same attribute cannot appear twice on one element.
Well-formed is not the same as valid
Well-formed means the syntax above holds. Valid means the document also matches a grammar, such as an XSD schema, a DTD or RELAX NG, which dictates which elements may appear, in what order, and with what data types. This tool checks well-formedness only. It does not fetch a URL, resolve an external DTD or apply a schema, so a document can format cleanly here and still be rejected by the system you are sending it to.
Before you minify
Minifying strips whitespace between elements to cut transfer size, and indenting puts it back. XML has no rule that collapses whitespace the way HTML rendering does, so text inside an element is data exactly as written. For most config files, feeds and API payloads the round trip is harmless: consumers ignore gaps between tags. Where spacing inside an element carries meaning, where the document sets xml:space="preserve", or where a digital signature covers it, use the formatted view to read the file and ship the original bytes.
Share this tool with friends
Free to use, no sign-up, works on any phone.
Frequently Asked Questions
Because something sits in front of the XML declaration. If a <?xml ... ?> line is present it has to be the very first thing in the document, with no blank line, comment or stray character before it. The commonest invisible cause is a UTF-8 byte order mark written by an editor or an export script. Strictly the spec permits a BOM as an encoding signature, but plenty of parsers report it as content once the bytes have been decoded to text. Delete everything before the first < and paste again; if it still fails, save the file as UTF-8 without BOM.
Well-formed means the document obeys XML's syntax rules: one root element, every tag closed and properly nested, reserved characters escaped, attribute values quoted, no attribute repeated on the same element. Valid means it additionally matches a grammar such as an XSD, a DTD or RELAX NG, which fixes the allowed elements, their order and their data types. This tool checks well-formedness only and never fetches or applies a schema, so a file can format cleanly here and still be refused by a validating consumer.
Usually a difference in case. XML is case sensitive, so <Order> can only be closed by </Order>; <order> is a different element name entirely. HTML tolerates the mix, which is where the habit comes from. Check the namespace prefix as well, since <ns:Order> needs </ns:Order>, and check that nesting does not cross over, because tags closed out of order fail with a similar mismatch message.
Yes. A bare & starts an entity reference, so a query string such as ?a=1&b=2 breaks the parse unless the ampersand is written &. A bare < starts a tag and must be <. Both rules apply inside attribute values too, where the quote character delimiting the value also has to be escaped. The > character is legal on its own and only strictly needs escaping as > where it would form the sequence ]]>, though many teams escape all three for consistency. For a large block of markup you do not want parsed, use a CDATA section: it holds raw & and <, but it cannot contain ]]>.
No. Exactly one element must enclose everything else, which is why joining two API responses or a run of log records into one file produces something no parser will accept, even though each fragment is fine on its own. Wrap them in a single container element and the document parses. Comments, processing instructions and whitespace are allowed outside the root, as is a DOCTYPE declaration before it; further elements are not.
Usually, but it is not automatic. Whitespace between elements is still character data that the parser hands over; most consumers of configuration files, RSS feeds, sitemaps and API payloads ignore it, so stripping it is safe there. It is not safe where text content itself is significant, since XML does not collapse whitespace the way HTML rendering does, and a section marked xml:space="preserve" is an explicit instruction to leave it alone. Re-spacing also invalidates an XML digital signature, because the signed bytes change. If in doubt, use the formatted output to read the document and ship the original bytes.