Is my XML uploaded anywhere?

No. Validation runs entirely in your browser; nothing is sent to a server.

Does this check against an XSD or DTD schema?

No — this checks only that the document is well-formed XML (every tag properly opened, closed and nested). It doesn't validate structure against a schema.

What's the difference between 'well-formed' and 'valid' XML?

Well-formed means the tags and syntax are correct on their own; valid additionally means the document conforms to a specific schema. This tool checks well-formedness only.

Why does it report only the first error?

XML parsers stop at the first structural problem, since later tags can't be reliably checked until the nesting up to that point is known to be correct.

XML Validator

Validate XML and find the exact line and column of the first well-formedness error — unclosed tags, mismatched tags, bad nesting. Runs in your browser.

Loading tool…

Worked examples

Well-formed XML with an attribute
Confirms a well-formed document passes cleanly, which is what most people check before feeding XML into a parser or build pipeline.
A tag that was never closed
A truncated or hand-edited document is a common mistake — the exact position where the parser gave up is reported.
Mismatched opening and closing tags
Swapped closing tags are easy to miss by eye in nested markup — the validator names which tag it expected and where it was originally opened.

What this tool does

This tool checks whether XML is well-formed — every tag properly opened, closed and correctly nested — and reports the exact line and column of the first problem if it isn't. It doesn't reformat or modify the document; it only tells you whether the XML is structurally sound and, if not, exactly where and why it broke.

When you need it

Debugging a "not well-formed" error from an XML parser in your application, where the runtime error message alone doesn't point at the actual line.
Checking a hand-edited config file — an Android manifest, an RSS feed, a SOAP request body — before it's consumed by something less forgiving about reporting where it failed.
Verifying XML received from an external system or API is actually valid before your code attempts to parse it, so a malformed response fails fast with a clear reason instead of an obscure downstream error.
Confirming a fix actually resolved a structural problem, by re-checking after editing.

Well-formed vs valid

These two words mean different things for XML, and it's worth being precise about which one this tool checks. "Well-formed" means the document follows XML's own syntax rules — tags are properly closed, nesting is correct, attribute values are quoted, and so on — independent of what the document is supposed to represent. "Valid" means the document additionally conforms to a specific schema (a DTD or XSD) that defines which elements and attributes are allowed where. This tool checks well-formedness only. A document can be perfectly well-formed while still being invalid against a particular schema — for example, using an element name a schema doesn't recognize, or omitting a required attribute. For schema validation, you need a validator built against that specific DTD or XSD.

Common errors this catches

The checker also rejects documents that have no content at all, more than one root element (<a/><b/>), text outside the root element, a < inside an attribute value, and entity references that are never declared (  is the usual culprit, since HTML entities do not exist in XML). Unclosed tags are the most frequent issue — a document that ends mid-element, often from truncated output or a copy-paste that missed the closing portion. Mismatched tags are the second most common: closing </a> when </b> was expected, typically from a hand-edit that swapped or misordered two adjacent elements. Both are reported with the exact position, and a mismatch names which tag was expected and where it was originally opened, so you don't have to manually count nesting levels to find the problem in a large document.

Why only the first error is shown

XML parsers, like most parsers, stop at the first structural problem — everything after an unclosed or mismatched tag is ambiguous until that problem is fixed, so reporting further "errors" from that point on would be guessing. Fix the first reported issue and re-check; if there's a second problem further down, it will surface on the next pass.

Limits

Input is capped at 2 MB of XML text. This tool checks well-formedness only, not validity against a DTD, XSD or any application-specific schema. It also does not check that namespace prefixes (<ns:tag>) are bound to a namespace, and it does not read an external DTD.

Frequently asked questions

Is my XML uploaded anywhere?: No. Validation runs entirely in your browser; nothing is sent to a server.
Does this check against an XSD or DTD schema?: No — this checks only that the document is well-formed XML (every tag properly opened, closed and nested). It doesn't validate structure against a schema.
What's the difference between 'well-formed' and 'valid' XML?: Well-formed means the tags and syntax are correct on their own; valid additionally means the document conforms to a specific schema. This tool checks well-formedness only.
Why does it report only the first error?: XML parsers stop at the first structural problem, since later tags can't be reliably checked until the nesting up to that point is known to be correct.