Checking XML for well-formedness
An XML validator of this kind answers one question: does the text follow XML's syntax rules closely enough that a parser can read it? Those rules are called well-formedness in the XML 1.0 specification. They cover nesting, quoting and escaping, and a conforming parser treats any violation as a fatal error. You get "Valid XML." or the first error.
The tool hands your input to the browser's DOMParser with the application/xml type. That's a strict XML parser, unlike the forgiving HTML parser browsers use for web pages, so it rejects things HTML would quietly fix.
Well-formed vs valid
The words get mixed up a lot, and this tool only does the first:
| Level | What it means | Checked here? |
|---|---|---|
| Well-formed | Correct syntax: one root, closed and properly nested tags, quoted attributes, escaped ampersands and less-than signs, no duplicate attributes, bound namespace prefixes | Yes |
| Valid (DTD) | Also follows the element and attribute rules in its DOCTYPE | No |
| Valid (XSD) | Also matches an XML Schema: element order, required attributes, data types | No, use XSD validation |
To prove the point, a document whose inline DTD says the root may only contain one kind of child, but which contains a different child, still reports "Valid XML." here.
Errors, as each browser reports them
The message comes from your browser's parser, so the wording varies. The validator strips the browser's boilerplate and adds the position, so a full message reads like "Invalid XML: Unexpected closing tag: from != to (line 2, column 17)". These are the reasons from real outputs:
| Problem | Chrome / Edge says | Firefox says |
|---|---|---|
| Closing tag doesn't match | Unexpected closing tag: from != to | mismatched tag. Expected: (the right closing tag) |
Bare & in text, e.g. "Smith & Sons" |
Unexpected token inside entity | not well-formed |
| Two root elements | Unexpected token | junk after document element |
| Unquoted attribute value | Unexpected token | not well-formed |
Case mismatch, Note vs note |
Unexpected closing tag: note != Note | mismatched tag |
HTML entity such as é |
Unexpected entity: eacute | undefined entity |
| Something before the XML declaration | Invalid processing instruction | XML or text declaration not at start of entity |
Undeclared prefix like x:b |
Element x:b prefix is unbound | prefix not bound to a namespace |
| Same attribute twice | Attribute 'id' is redefined | duplicate attribute |
Every major browser reports a line and column, though they sometimes point at slightly different characters: for the mismatched closing tag above, Chrome gives column 17 (the end of the bad tag) and Firefox column 13 (its start).
Fixing a document step by step
- Paste the XML and click Validate.
- Read the line and column, go there, and look at that spot and the line before it. A missing closing tag is often reported where the parser first notices, which can be several lines later.
- Fix it and validate again. Only one error is shown per run, so repeat until you see "Valid XML."
- Once it's well-formed, use the XML formatter to re-indent it so the nesting is easy to read.
Three traps worth knowing
The declaration must be first. <?xml version="1.0"?> is only allowed at the very start of the document. Even a single blank line or space before it is an error, which happens a lot when copying from logs or code strings. Delete everything before it.
Escaping inside text and attributes. A literal ampersand must be written & and a less-than sign <, including in URLs with query strings (?a=1&b=2). Wrapping a block in CDATA avoids escaping for that block.
Namespaces count. If an element or attribute uses a prefix, that prefix has to be declared with xmlns:prefix="..." on the element or an ancestor (Namespaces in XML). Fragments cut out of a larger SOAP or Atom document often lose their declarations this way.
Where to go next
Once the document parses, the XPath evaluator lets you query it, and the online XML editor is better for longer editing sessions with syntax highlighting.
Last updated