Check XML well-formedness with the exact line and column of the first error — for an unclosed tag, the line where it opened too — plus a structural summary of root, elements, comments and depth. Free, no sign-up — runs locally in your browser.
Why a validator, when the formatter exists?
Different question, different tool. The formatter answers
“make this readable”; this validator answers the go/no-go
question that comes before it in most pipelines: “is this
document safe to hand to a parser at all?” A sitemap rejected
by a crawler, a feed that silently stops updating, a config
file a service refuses at boot — all of these are one
well-formedness error wearing different clothes, and all of
them are much cheaper to find here, with a line and column
attached, than from a log file after the fact. The verdict
box also summarises the document — root element, element
count, comments, CDATA sections, maximum nesting depth — so
you can confirm you pasted the document you meant to check.
How to use this tool
- Paste the XML, upload a
.xml file, or drop one onto the panel. With “Validate as I type” on, the verdict updates as you edit. - Press Validate XML. A ✓ verdict means every tag closes in order, attributes are well formed, and the document has exactly one root.
- On a ✗ verdict, read the message: it gives the line and column of the offence and, for an unclosed tag, the line where the tag opened. Fix, re-validate, repeat — parsers report one error at a time.
- If your document is an SVG, RSS or Atom file it validates here too — they are all XML. Remember the scope line: this checks well-formedness, not conformance to the SVG or RSS schemas.
What it checks — and what it does not
Checked: tag balancing and nesting order, exactly one root
element, quoted and duplicate-free attributes, the
<tag/> and ---free comment
rules, CDATA section structure, legal entity references
(the five built-ins plus numeric references), XML declaration
placement and text outside the root. Not checked: DTD or XSD
validity, namespace meaning beyond well-formed
prefixed names, and anything that would require fetching an
external file. That boundary is deliberate and matches what
most XML-consuming code enforces first.
The errors people actually hit
An ampersand in a URL or text — write
&, never a bare &.
A hyphen too many — comments may not contain
-- anywhere inside. Case drift —
<Item> does not close with
</item>. Two roots — an XML
document has exactly one root element; fragments need a
wrapper. An attribute written twice after a
template merge. Every one of these gets a precise verdict
here, before your pipeline finds it the hard way.
Frequently asked questions
What exactly does "well-formed" mean here?
That the document obeys XML's structural grammar: one root element; every start tag closed in correct nesting order with matching case; attribute values quoted and unique per element; legal characters and entity references; comments, CDATA sections and the XML declaration properly formed. A well-formed document can be parsed by any conforming XML parser. It does not promise the document contains the elements your application expects — that is validity, next question.
What is the difference between well-formed and valid?
Validity means the document also satisfies a schema — a DTD or XSD that names the allowed elements, their order and their content types. This tool checks well-formedness only: it does not fetch or apply DTDs or schemas, and it does not resolve external entities. If your pipeline needs schema validation, this checker is the fast first gate; the schema step belongs in your build, with the schema file beside the document.
How precise is the error location?
As precise as the parser can make it: the message names the line and column where the problem is detected, and for an unclosed tag it also names the line where that tag opened — which is where the fix usually belongs. XML parsers stop at the first error, so repair the reported spot and validate again; a second error may be waiting behind the first, and that loop is normal, not a defect in the document beyond the two spots.
Why does it reject a document my browser renders fine?
Because browsers parse XML content with HTML parsers when they can, and HTML parsing is error-correcting by design — it guesses. The parser behind this tool is the same strict one the XML Formatter uses, and strictness is the point: feed readers, sitemap consumers, SOAP services and most programming-language libraries use real XML parsers that refuse what a browser forgives. Passing here means those parsers will accept the structure too.
Is validating code from untrusted sources here safe?
Yes, in the way that matters for pasting: the check runs entirely in your browser, the text is never uploaded, and the parser does not resolve external entities or fetch anything — the classic XXE attack surface of server-side validators simply does not exist here. The document summary (element counts, comments, CDATA sections, nesting depth) is computed from the parse tree, not by sending the file anywhere.
Dev