XML validator — check well-formedness
Check whether XML is well-formed and get the line, column and a plain-English explanation of the first error instead of a cryptic parser dump.
- Runs in your browser
- Files are never uploaded
- Free, no account
Your XML never leaves this tab — check it yourself—
Starting the network probe…
The counter above wraps fetch, XMLHttpRequest and navigator.sendBeacon in this tab and counts every call. It does not block anything — it just reports.
Two ways to verify independently
- Turn off Wi-Fi or enable airplane mode, then use the tool. It keeps working, because the page is already fully loaded.
- Open your browser devtools, switch to the Network tab, clear it, and run the tool. No new row appears.
Why this matters
In 2025 researchers found that popular online formatters had retained tens of thousands of user-submitted snippets — JSONFormatter.org and CodeBeautify together exposed roughly 80,000 saved documents, many containing live cloud credentials, private keys and internal database connection strings, because “format this” quietly meant “upload this”. A separate incident exposed roughly 3.5 million user PDFs on a document-conversion service. The only structural fix is not sending the data in the first place: this site is served under a Content-Security-Policy whose connect-src contains no third-party origin, so a request off this device cannot be made even by accident.
Well-formed is not the same as valid
XML has two distinct levels of correctness, and mixing them up wastes a lot of time.
Well-formed means the document obeys XML’s syntax: one root element, every
tag closed and correctly nested, attributes quoted, entities defined, no stray
& or <. Valid means it also conforms to a
specific schema — a DTD, XSD or RELAX NG grammar that says which elements may appear where.
This page checks well-formedness, which is what catches the overwhelming majority of real failures, and it does so with the browser’s own parser. Schema validation needs the schema file and a validating processor, which is a build-pipeline job rather than a browser one.
The errors, and what each one really means
| Message | Cause | Fix |
|---|---|---|
| Mismatched tag | A closing tag does not match the opening tag. XML is case-sensitive. | <Item> must close with </Item>, never </item> |
| Premature end of data | The document ends with elements still open | Find the last unclosed tag — usually near a truncated copy-paste |
| Entity not defined | An HTML entity such as | Use a numeric reference:   |
| Not well-formed / invalid token | A bare & or < in text | Escape them as & and < |
| Junk after document element | More than one root element | Wrap everything in a single container element |
| XML declaration allowed only at the start | A blank line, a BOM or a comment before <?xml | Delete whatever precedes it, including invisible bytes |
| Prefix not bound | A namespace prefix used without a declaration | Add the matching xmlns:prefix="…" |
| Duplicate attribute | The same attribute set twice on one element | Remove the repeat |
| Specification mandate value for attribute | A boolean-style attribute with no value | XML requires name="value" for every attribute |
Why the ampersand causes so much trouble
A raw & is the single most common cause of an invalid XML document, and it
almost always arrives through data rather than through hand-written markup: a company name
(“Smith & Sons”), a URL with query parameters
(?a=1&b=2), or a value that was already HTML-escaped once. When a value is
interpolated into a template without escaping, every ampersand in the data becomes a syntax
error. Escape at the point of insertion, not afterwards.
Only five entities exist
XML predefines &, <, >,
" and '. That is the complete list. HTML’s
roughly two thousand named entities are not available unless a DTD declares them, which is why
documents copied out of an HTML context fail here. Every character can still be written as a
numeric reference — — or — for an em dash — or, in
a UTF-8 document, simply typed literally.
After it passes
A well-formed document is the floor. It says nothing about whether required elements are present, whether values are in range, or whether the service you are sending it to will accept it. If you have an XSD, validate against it in your build. If you are debugging an integration, a formatted, well-formed document is the point at which you can start reading the actual content — switch to the tree viewer for anything large.
Questions
What counts as an error?
Anything that stops the document being well-formed: a closing tag that does not match its opening tag (XML is case-sensitive), an unquoted attribute value, a bare & or <, an undefined entity such as , more than one root element, or content after the root closes.
Why does fail?
XML predefines exactly five entities: & < > " and '. Everything else has to be declared in a DTD. HTML entities such as , © and — are not available — write the numeric reference instead, for example   for a non-breaking space.
The error mentions a namespace prefix that is not bound. What does that mean?
You used something like `<soap:Envelope>` without a matching `xmlns:soap="…"` declaration in scope. Add the declaration on that element or an ancestor. Copy-pasting a fragment out of a larger document is the usual cause.
Does a valid result mean my API will accept it?
It means the document parses. It does not mean it matches the schema the service expects, that required elements are present, or that values are in range. Well-formedness is the floor, not the ceiling.