About XML Validator
XML Validator parses a document with the browser's own XML parser and tells you whether the markup is well formed. When it is, the report names the root element and counts every element in the document; when it is not, the parser's message is shown instead, including the line and column where it gave up.
XML has two separate notions of correctness, and conflating them wastes debugging time. Well-formedness is a property of syntax: one root element, every tag closed and matched case-sensitively, attribute values quoted, reserved characters escaped, every namespace prefix declared before use. Validity is a property of content measured against a schema — an XSD, a DTD, or RELAX NG — which says which elements may appear where, in what order, with what types. This tool answers the first question completely and the second not at all, which is what you want when a consumer rejected a document and you do not yet know which kind of problem you have.
How to use this developer tool
- Paste the document, including the XML declaration and any DOCTYPE, into the XML pane.
- Watch the status in the pane header: it re-parses as you type, so the document turns valid the moment the last tag is closed.
- Run the validation to get the report with the root element name and the total element count.
- If parsing fails, go to the reported line and column, then read backwards — a missing quote or unclosed tag is usually several lines above where the parser noticed.
- Once the syntax is clean, run schema and business-rule checks separately with a processor that understands your XSD.
Worked example: well formed and still wrong
This order document is syntactically perfect: a default namespace, correct nesting, quoted attributes, every element closed. The validator accepts it, and a schema would still reject it.
<?xml version="1.0" encoding="UTF-8"?>
<order xmlns="urn:example:orders" id="A-1001">
<customer>Ada Lovelace</customer>
<line sku="DT-100" qty="2"/>
<line sku="DT-220" qty="one"/>
<total currency="EUR">59.00</total>
</order>XML valid
Root element: order
Element count: 5The count of 5 includes the root itself: order, customer, two line elements, and total. Note what the report cannot tell you — qty="one" is not a number, and an XSD declaring that attribute as xs:integer would reject the document immediately. Well formed is a statement about angle brackets, not about meaning.
Which rule is checked here, and which needs a schema
The first group is syntax and is enforced by every conforming XML parser. The second is content and requires a grammar that describes your format.
| Rule | Well-formedness | Schema validity |
|---|---|---|
| Exactly one root element, with only comments and processing instructions outside it | Checked here | — |
| Every start tag has a matching end tag, spelled with identical case | Checked here | — |
| Attribute values are quoted, and no attribute repeats on one element | Checked here | — |
| Reserved characters are escaped and every entity reference resolves | Checked here (write & for a literal ampersand) | — |
| Every namespace prefix is declared on the element or an ancestor | Checked here | — |
| Child elements appear in the required order and the required number of times | — | XSD, DTD, or RELAX NG |
| An attribute holds an integer, a date, or a value from an enumerated list | — | XSD |
| The namespace URI is the one the consumer expects, not merely a valid URI | — | XSD or application code |
| Two fields agree, for example a total equal to the sum of its lines | — | Schematron or application code |
Troubleshooting
The parser reports that a namespace prefix is not defined.
Why it happens An element or attribute uses a prefix such as dc: or soap: with no matching xmlns:dc declaration on that element or an ancestor. This almost always happens because a fragment was copied out of a larger document that declared the prefix on its root.
Fix Add the declaration to the outermost element of the fragment. A prefix is only a local alias; what identifies the vocabulary is the URI it is bound to, so copy the exact URI from the source document rather than inventing one.
A file that fails in your build passes here, or the reverse.
Why it happens Encoding. A file on disk is a sequence of bytes and the declaration tells a parser how to decode them, so a UTF-8 file declared as ISO-8859-1 breaks. Text pasted into this page has already been decoded by the browser, making the declaration effectively advisory here.
Fix Verify the real encoding with a tool that reads bytes, then make the declaration match how the file was saved. Watch for a UTF-8 byte order mark before the declaration, which several strict parsers reject.
An entity such as is reported as undefined.
Why it happens XML predefines only five entities: &, <, >, ", and '. Everything else, including the whole HTML set, must be declared in a DTD, and browsers do not fetch external DTDs.
Fix Use a numeric character reference instead —   for a non-breaking space — or declare the entity in the internal subset of the DOCTYPE. Do not rely on the consumer fetching an external DTD; many parsers disable that by default.
The document is well formed here but the receiving system still rejects it.
Why it happens You have a validity problem rather than a syntax problem: a missing required element, a value of the wrong type, an element out of order, or the right element names under the wrong namespace URI.
Fix Ask for the XSD or the exact error the consumer produced, then validate against that schema with xmllint, a language-level schema library, or the vendor's own validator. This tool deliberately stops at syntax.
When this tool is the right choice
- Deciding quickly whether a rejected payload has a syntax problem or a content problem.
- Checking that markup produced by a template or string concatenation is well formed before a strict parser sees it.
- Confirming the root element name and size of an unfamiliar document, which often identifies which format you were sent.
- Sanity-checking a hand-edited configuration file after a merge conflict left stray markers in it.
When to use something else
- Validating against an XSD, DTD, or RELAX NG grammar. There is no schema input here; use xmllint or your platform's validating parser.
- Re-indenting or compacting a document. The XML Formatter & Minifier does that and preserves mixed content correctly.
- Checking HTML. HTML5 is not an XML dialect and permits unclosed tags, unquoted attributes, and bare ampersands that this parser rejects; use the HTML Previewer.
Privacy and data handling
Parsing happens in this browser tab using the platform DOMParser. The document is not uploaded and does not survive the tab being closed. External resources referenced by a DOCTYPE are not fetched, which is both a privacy property and the correct security posture, since fetching external entities is the mechanism behind XXE attacks. XML configuration files routinely hold connection strings and passwords in plain attributes, so redact those first.
Related developer tools
Frequently asked questions
What is the difference between well-formed and valid XML?
Well-formed describes syntax: one root element, correctly nested and closed tags, quoted attributes, escaped reserved characters, declared namespace prefixes. Valid describes content against a declared schema. Every valid document is well formed; the reverse is not true, and most rejected documents in practice are well formed but invalid.
Does the validator check my XSD?
No. It parses the document and reports well-formedness only. Schema validation needs the schema itself, which this tool does not accept. Use xmllint with the --schema option, or the validating parser in your language, once the syntax is clean.
Are external entities or DTDs loaded?
No. The browser parser does not fetch external resources referenced by a DOCTYPE, so nothing leaves your machine and the document cannot pull in a file from your network. Secure server-side parsers are configured the same way, because external entity resolution is the basis of XXE attacks.
Why does XML care about tag case when HTML does not?
XML is case-sensitive by design, so Item and item are different element names and a document mixing them is not well formed. HTML parsers normalize tag names, which is one of several reasons HTML cannot be treated as XML without conversion to XHTML.
Is the XML declaration required?
It is optional for a UTF-8 document using XML 1.0, since that is the default assumption. Include it whenever the encoding is anything else, or whenever the document will be written to a file whose encoding a consumer might have to guess.
What does the element count include?
Every element in the document, including the root, at any depth. Comments, processing instructions, attributes, and text nodes are not counted. It is a quick way to see whether a document is the size you expected, which often catches a truncated transfer.