What this XML validator checks
This XML validator tests whether a document is well-formed: whether it follows the syntax rules that every XML parser enforces. A file that fails this check will be rejected by any parser, whether it is a Java SAX parser, .NET's XmlDocument, Python's ElementTree or a browser. When the document passes, the status bar confirms it and names the root element and the number of elements, and the output panel shows it neatly indented.
Well-formed versus schema-valid
It is worth being precise, because the word "valid" means two things in XML:
- Well-formed – the syntax is correct. This is what the tool checks.
- Valid against a schema – the document also matches an XSD, DTD or RELAX NG definition: the right elements, in the right order, with the right data types. This tool does not load or apply schemas, and a
<!DOCTYPE>line is accepted but not used to check the content.
Well-formedness is the first gate. If you are debugging an integration that rejects your file, confirm it here first; if it passes, the problem is in the schema or the content rules of the receiving system.
The rules, with the errors you get when they break
| Rule | Breaks it | Reported as |
|---|---|---|
| Every start tag has a matching end tag | <a><b>x</a> | Expected closing tag 'b' … instead of closing tag 'a' |
| Names are case-sensitive | <Item></item> | Expected closing tag 'Item' … |
| Exactly one root element | <a/><b/> | Multiple possible root nodes found |
| Attribute values are quoted | <b id=1> | Attribute 'id' is without value |
| No attributes without a value | <input checked/> | boolean attribute 'checked' is not allowed |
| No repeated attributes | <b x="1" x="2"/> | Attribute 'x' is repeated |
| Ampersands in text are escaped | <b>Tom & Jerry</b> | char '&' is not expected |
| Names cannot start with a digit | <1st/> | Tag '1st' is an invalid name |
| The file is complete | <a><b>ok</b> | Unclosed tag 'a' |
For a mismatched closing tag, the message also tells you where the unclosed element was opened, for example (opened in line 2, col 3), which saves a lot of scrolling in long files.
Example
This order looks fine at first glance:
<order id="1042">
<customer>Ava Martinez</customer>
<note>Leave with R&D reception</note>
</order>The validator stops at line 3 because of the bare & in "R&D". Change it to R&D, or wrap the text in <![CDATA[ ... ]]>, and the status bar reports Valid XML ✓ — root <order>, 3 elements.
Limits worth knowing
The check is a fast syntax pass, not a full XML processor. A few problems a strict parser would also flag are not reported here:
- Namespace prefixes that were never declared, such as
<soap:Envelope>without anxmlns:soapattribute. - Entity references that XML does not define, such as
, which is an HTML entity. In XML use the numeric reference instead. - A raw
<or&inside an attribute value. Escape them as<and&. - A double hyphen inside a comment, such as
<!-- a -- b -->, and the sequence]]>in ordinary text. - Control characters, and character references to characters XML does not allow, such as
�. - An XML declaration that is not at the very start of the document, for example inside the root element.
If a document passes here but your application still rejects it, look for these first. The XML escape tool converts special characters in a snippet for you.
Related tools
To tidy the document after fixing it, use the XML formatter. To query the validated file, try the XPath tester.
Privacy
Validation happens in your browser, so the XML is not uploaded. Only Load URL, which fetches through our server, and Save & Share, which stores the input to create a link, send data to us.