Check your XML
Mismatched tags, undefined entities, broken namespaces — found and located precisely, by the browser's own XML parser. Nothing is stored.
- Never stored
- No queue, no waiting
- No signup, no watermark
Paste XML and it is checked as you type.
How it works
Paste your XML
Or drop the file in. Nothing is sent anywhere.
Read the verdict
Well-formed, with a summary of what is inside. Or the exact line and column of the first problem.
Fix and re-check
Edit in place; the answer updates as you type.
Two different bars, and which one this is
XML defines two levels of correctness and they are routinely confused. Well-formed means the document obeys XML's own syntax: one root element, every tag closed, correct nesting, legal characters, properly escaped ampersands and angle brackets, quoted attribute values, unique attribute names within an element. Valid means something stronger — that the document also matches a particular schema, with the right elements in the right order carrying the right kinds of value. This page checks the first. Every XML parser refuses a document that fails it, so it is the check that decides whether a file can be read at all.
The failures are predictable. An unescaped & is the most common by a wide margin — it starts an entity reference, so a URL with a query string pasted straight into an element breaks the document. A bare < in text does the same. Then mismatched or unclosed tags, elements closed in the wrong order, two root elements, and a stray control character that XML does not permit at all even though it sits invisibly in the file.
A DTD or schema is deliberately never fetched, and that is a security property rather than a missing feature. An XML document can name an external entity and a parser that resolves it will go and fetch what it points at — a file on disk, an address on an internal network. That is the XML External Entity vulnerability, one of the most exploited classes of bug there is, and the only complete defence is not to resolve them. So nothing here reaches out to anything, and the cost is that validation against a schema is out of scope.
What you get is the exact line and column where parsing stopped. As with any parser, that is where the document stopped making sense rather than where the mistake is: an unclosed tag is usually reported at the unexpected closing tag that follows it, sometimes hundreds of lines later. The reported position is where to start looking upward, not where to edit.
When you want something else
To validate against a schema, xmllint is the reference tool: xmllint --noout --schema schema.xsd file.xml for XSD, --relaxng for RELAX NG, and --noout --valid for a DTD. It reports every violation rather than stopping at the first, which is what you want when a document is genuinely wrong rather than merely broken.
For anything involving untrusted input, the parser configuration matters more than the validator. Turn off external entity resolution and DTD processing explicitly in whatever language you are using — defusedxml in Python, LIBXML_NONET in PHP, secure processing in Java — because several popular parsers still resolve entities by default, and the default is where the vulnerability lives.
Frequently asked questions
Is my XML stored anywhere?
No. There is no server call and no logging, and nothing is stored. You can disconnect from the internet after the page loads and it keeps working. That matters here more than it looks: the things people paste into an online formatter are API responses, config files and error payloads, and those routinely carry tokens, customer records and internal hostnames.
What does "well-formed" mean?
That the document obeys XML's own rules: every tag closed, tags nested in the right order, exactly one root element, attributes quoted, and every & and < either escaped or part of a valid entity. It is the first of two questions you can ask about XML. The second — whether the document matches a particular schema — is separate, and this page does not answer it.
Does it validate against a DTD or XSD schema?
No. This checks that the document is well-formed XML, which is the failure most people are actually looking at. Schema validation needs your schema file and a validating parser, and no browser ships one; claiming to do it here would mean either sending your document to a server or quietly not checking. The distinction is worth knowing: a document can be perfectly well-formed and still wrong for its schema.
What are the most common XML errors?
A bare ampersand is the usual one — & must be written &, even inside a URL, so a query string pasted straight into an element breaks the document. After that: a tag closed in the wrong order, two root elements, an undefined entity like (which HTML defines and XML does not), and a namespace prefix used without being declared. Each is reported by name with its position.
Is HTML valid XML?
Usually not, and that is normal rather than a mistake. HTML allows unclosed tags like <br> and <li>, unquoted attributes and bare ampersands; XML allows none of them. If you need HTML that is also valid XML, that is XHTML, and it must close every tag.
Is there a size limit?
Available memory, rather than a cap we impose. Documents of a few megabytes format instantly; very large ones are limited by how much can be held at once, not by anything on our side.
Good to know: Well-formedness, not schema validation. Balanced tags, correct nesting and legal characters are checked and you get the exact line and column of the first problem. Validating against a DTD or XSD would mean fetching it, which is a network request this page deliberately never makes.
Put this tool on your website
Free for any blog, class page or help article. Paste one snippet and your visitors can use it right on your page.