Skip to content
Browser tool Runs locally

XML Validator

Paste XML to check whether it is well-formed. Runs locally in your browser.

Input XML
0 chars
Validation result
Paste XML in the input panel, then click Validate XML.

What is XML validation?

This tool checks whether a document is well-formed: tags are properly matched and nested, attributes are quoted, there is exactly one root element, and reserved characters are escaped. Well-formedness is the baseline every XML document must meet - it's a separate question from whether the document follows a particular schema.

How to use this validator

  1. Paste or type XML in the input panel.
  2. Click Validate XML - or press ⌘/Ctrl + Enter.
  3. Read the result, including the root element and element count on success.

Common errors: unclosed tags, mismatched tags, and unescaped ampersands

Three mistakes account for most well-formedness failures. An unclosed tag - an opening tag with no matching closing tag, or a non-empty element missing its / - leaves the parser unable to tell where that element ends. A mismatched tag, where the closing tag's name doesn't match the opening tag it's meant to close, breaks the nesting the parser is tracking. And a bare ampersand in text content or an attribute value is invalid on its own, since the parser reads it as the start of an entity reference - it needs to be written as an escaped entity instead.

Attributes, nesting, namespaces, and XML declarations

Attribute values must always be quoted, with single or double quotes, and elements must nest strictly - an element opened inside another must close before its parent does, so overlapping tags are never valid. Namespaces, declared with an xmlns attribute and referenced with a prefix, are part of well-formedness only in the sense that a prefixed element or attribute must have its namespace declared somewhere in scope; the validator doesn't check that a namespace resolves to any particular meaning. An XML declaration at the top of the document, if present, must come first, before any other content, but it's optional for a document to be well-formed.

A practical validation workflow

When XML from an API, a config file, or a generated report fails elsewhere, running it through a dedicated well-formedness check first narrows down whether the problem is basic syntax or something more specific, like a missing required element under a schema. Fix the reported line and column, revalidate, and repeat - well-formedness errors are often chained, so an early mistake like an unclosed tag can cause the parser to misread everything after it, producing a second error that disappears once the first is fixed.

Browser-based validation limitations

This validator uses the browser's built-in XML parser, which means it checks well-formedness reliably but doesn't validate against a DTD or XSD schema, doesn't resolve external entities or DTDs referenced from the document, and reports errors using the message and location format that specific browser's parser produces - wording can vary slightly between browsers even for the same mistake. For schema-level validation, a dedicated DTD or XSD validator is needed in addition to this check.

Frequently asked questions

Is my XML uploaded to a server?
No. Validation runs entirely in your browser using the browser's own XML parser, so the document never leaves your machine.
What does this validator check?
Well-formedness - that every tag is properly opened, closed, and nested, that attribute values are quoted, that there is exactly one root element, and that special characters like a bare ampersand are escaped. It does not check the document against a DTD or XSD schema, so it can't tell you whether specific elements or attributes are allowed for your format.
What's the difference between well-formed and valid XML?
Well-formed means the XML follows the base syntax rules - matched tags, quoted attributes, one root element, escaped special characters. Valid means the document also conforms to a specific schema (a DTD or XSD) that defines which elements, attributes, and structure are allowed. This tool checks well-formedness only; schema validation needs the specific schema the XML is meant to follow.
What does the error location mean?
When the browser's parser reports one, the result shows the line and column where parsing failed - typically the point where the parser could no longer make sense of the structure, which is often at or just after the actual mistake, such as a missing closing tag or an unescaped character.
Why does my XML fail even though it renders fine in a browser tab?
Some browsers are lenient about certain issues, like an unescaped ampersand in specific contexts, when just displaying a page. A strict well-formedness check applies the full XML syntax rules regardless of how forgiving a particular renderer happens to be, so it can catch problems that don't visibly break the page.

Related tools