Well-formed is the first gate
Every XML consumer, from a SOAP client to an Android build, refuses a document that is not well-formed. The rules are short but unforgiving:
- Every start tag has a matching end tag, nested in the right order, and names match case-sensitively (
<Order>is not closed by</order>). - There is exactly one root element; text or a second element after it is an error.
- Attribute values are always quoted, and the same attribute cannot appear twice on one element.
&and<inside text must be escaped as&and<unless they sit in a CDATA section.- Element names cannot start with a digit, comments must end with
-->, and CDATA sections must end with]]>. - Character references like
—must be well-formed hex or decimal.
The validator checks all of these with a built-in tokenizer and reports the first error with its line and column. Because XML names are case-sensitive, a mismatch like </A> closing <a> gets its own hint suggesting the correctly cased tag, a mistake that is easy to make when HTML habits creep into an XML feed.
Messages written for humans
Instead of an offset into the file, you get sentences like “Expected </item> to close <item> opened at line 4, found </order>”, which names both ends of the problem. Hints follow where they help (“Write & for a literal ‘&’”). The editor highlights the offending line and the right-hand pane keeps showing the last well-formed version, dimmed, until the document parses again. On large files, press Ctrl/Cmd+Enter to validate when you are ready rather than on every keystroke.
Some findings are warnings, not errors. An entity such as that is not one of the five XML built-ins and is not declared in a DOCTYPE is flagged, because strict parsers reject it while lenient ones pass it through. Whitespace before the <?xml ?> declaration is reported and removed.
Safe with untrusted documents
Entities declared in a DOCTYPE are recognised but never expanded. That means a “billion laughs” payload, where nested entities multiply into gigabytes, cannot freeze the tab, and external entities are never fetched, so there is no XXE risk. Combined with the fact that the document never leaves your browser, you can paste a suspicious file from a bug report and inspect it safely.
What this validator does not check
Well-formedness is not the same as validity against a schema. The validator does not load DTDs, XSD files or RELAX NG grammars, so an <invoice> missing a required <total> element passes. Namespace prefixes are not resolved either: a dc:title element without an xmlns:dc declaration is accepted here even though a namespace-aware parser would complain. For schema validation use your build tooling, for example xmllint --schema. Once the document is well-formed, the XML formatter can indent it and the XML to JSON converter can turn it into data.
Examples
Element left open inside an order
Invalid: <item> is never closed, and the message names both the open tag and the </order> that was found instead.
<order id="ord_8f2k1">
<customer>Aisha Tan</customer>
<item sku="KB-104" qty="1">
</order>Line 4, column 1: Expected </item> to close <item> opened at line 3, found </order>Raw ampersand in a company name
Invalid: the & must be written as & because it would otherwise start an entity reference.
<supplier>
<name>Smith & Sons</name>
<country>SG</country>
</supplier>Line 2, column 15: Unescaped '&' — it must start an entity reference like & or &Two RSS documents pasted together
Invalid: XML allows exactly one root element, so the second <rss> is reported.
<rss version="2.0"><channel><title>Shop news</title></channel></rss>
<rss version="2.0"><channel><title>Archive</title></channel></rss>Line 2, column 1: Only one root element is allowed — <rss> follows the root element <rss> that closed at line 1Well-formed, with an undeclared entity
The document is well-formed, but earns a warning because only five entities are built into XML.
<p>Price: 12.00 SGD</p><p>Price: 12.00 SGD</p>
Common errors and how to fix them
| Error | Cause | Fix |
|---|---|---|
Expected </item> to close <item> opened at line 3, found </order>Explained | An element was left open or closed in the wrong order. | Add the missing end tag or swap the end tags so they nest correctly. |
Unescaped '&' — it must start an entity reference like & or &Explained | A literal ampersand appears in text or an attribute value. | Replace it with &, or wrap the text in a CDATA section. |
Only one root element is allowedExplained | Two top-level elements, often from concatenated files or a missing wrapper. | Wrap the elements in a single parent element. |
Text is not allowed before the root elementExplained | Stray characters, such as a log prefix or an HTTP status line copied with the body, appear before the first tag. | Delete everything before the XML declaration or root element. |
The value of attribute 'x' must be in quotesExplained | An attribute was written HTML-style without quotes. | Quote the value: x=“1”. |
Frequently asked questions
What is the difference between well-formed and valid XML?
Well-formed XML follows the syntax rules: matched tags, one root, quoted attributes, escaped characters. Valid XML is well-formed and also conforms to a DTD or XSD. This page checks well-formedness.
Can it validate against an XSD?
No. It does not load schemas. Use xmllint --schema or your IDE for XSD validation once the document is well-formed.
Is it safe to paste XML with a DOCTYPE from an unknown source?
Yes. Declared entities are never expanded and external resources are never fetched, so entity-expansion and XXE attacks have no effect.
Does it work for SVG, RSS, XHTML and .csproj files?
Yes, they are all XML. For SVG there is also a dedicated SVG formatter that checks the root element and warns about embedded scripts.