XML Formatter & Validator

Pretty-print or minify XML and find out exactly where a malformed document breaks, reported by line and column.

Result

Well-formed and valid are different things

These two words get used interchangeably and they are not the same test. Well-formed means the document obeys the syntax of XML: one root element, tags properly nested and closed, attributes quoted, characters escaped. A parser can check that on its own.

Valid means the document additionally conforms to a schema — a DTD, an XSD, or a Relax NG grammar — that says which elements are allowed, in what order, with what attributes. Validation requires that schema; XML itself does not carry one by default.

This tool checks well-formedness only, using your browser's parser. It will tell you that <price>abc</price> is perfectly good XML, because it is — nothing in XML says a price has to be a number. That constraint lives in your schema.

What the browser parser will reject

ProblemExampleWhy it fails
Unclosed tag<a><b></a>Tags must nest, never overlap
Two roots<a/><b/>Exactly one root element is allowed
Unescaped &<t>A & B</t>& always starts an entity
Unquoted attribute<a id=1>Attribute values must be quoted
Undeclared prefix<dc:title> with no xmlns:dcA namespace prefix must be bound
Lowercase mismatch<Tag></tag>XML is case-sensitive; HTML is not

The last one is the most common mistake when someone writes XML by hand after years of writing HTML. Browsers silently accept mismatched case in HTML; an XML parser is required to reject it.

Five characters that must be escaped

Inside element content you must escape & and <. Inside an attribute value you must also escape the quote character you used as the delimiter. The other three are conventional rather than required, but escaping them avoids surprises:

CharacterEscape asRequired?
&&amp;Always
<&lt;Always
>&gt;Recommended (required after ]]>)
"&quot;In double-quoted attributes
'&apos;In single-quoted attributes

Order matters when escaping: replace & first, or you will double-escape the ampersands you just introduced and end up with &amp;lt;.

CDATA is not an escaping shortcut

<![CDATA[ ... ]]> tells the parser to treat everything inside as literal text, so < and & need no escaping. It is genuinely useful when you are embedding code or markup as text.

Two caveats: the sequence ]]> terminates the section, so content containing it has to be split across two CDATA blocks; and a CDATA section is not recognised inside an attribute value. It also hides the content from anything doing schema validation or XPath on the text, which is why overuse causes problems later.

Namespaces are URIs, not addresses. xmlns="http://example.org/ns" looks like a location, but nothing is fetched from it. It is an opaque identifier, and two documents are in the same namespace only if those strings are byte-identical — including trailing slash and case.

Frequently asked questions

Why does my valid-looking XML fail to parse?

Most often an unescaped ampersand in a URL, or a stray character before the declaration — even a space or a byte order mark ahead of <?xml will break it.

Should I use attributes or child elements?

Attributes suit metadata about the element — an id, a currency, a language code. Child elements suit data that may itself grow structure, repeat, or need to hold mixed content. Attributes cannot repeat and cannot contain markup, so anything that might become complex belongs in an element.

Is XML still worth using over JSON?

For new APIs, JSON usually wins on size and ergonomics. XML still has real advantages where document-like, mixed content matters, and where schema validation, namespaces and transformation tooling are already part of the pipeline — publishing, enterprise integration, office document formats.

Can this validate against my XSD?

No. This checks well-formedness using the browser's XML parser. Schema validation needs the schema document and a validating processor; most browser parsers deliberately do not fetch or apply external schemas.

Privacy. Parsing happens in your browser. Your document is never uploaded, so it is safe to paste internal or customer data here.