What does this validator actually check?

It checks well-formedness: every opening tag has a matching closing tag (or is self-closed), tags aren't overlapped, attribute syntax is valid, and the document has exactly one root element. It does not check the document against an XSD or DTD schema, that's a separate kind of validation this tool doesn't perform.

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

Well-formed means the document follows XML's own syntax rules, matched tags, proper nesting, one root element, regardless of what the tags mean. Valid (in the stricter sense) means the document additionally conforms to a schema (XSD or DTD) that defines which elements and attributes are allowed where. Every valid document must be well-formed, but plenty of well-formed documents aren't valid against any particular schema. This tool checks the former.

What happens when my XML has an error?

The validator reports the exact line and column where parsing stopped, along with a specific message, an unclosed tag, a mismatched closing tag, or a malformed tag, so you can jump straight to the problem instead of scanning the whole document by eye.

Does this tool send my XML to a server?

No. Validation runs entirely client-side in your browser using a hand-rolled parser, not a network call to a validation API. Nothing you paste is uploaded, which matters for documents containing real configuration or customer data.

Why does it report an element count and nesting depth?

Those stats are a quick sanity check on document shape, useful for spotting an accidentally duplicated section, confirming a document matches roughly the size you expected, or noticing unexpectedly deep nesting that might indicate a bug in whatever generated the XML.

XML Validator - Check XML Well-Formedness Online

Overview

Introduction

XML's strict syntax rules are exactly what make it reliable for machine-to-machine exchange, but that strictness also means one missing closing tag or one malformed attribute can break an entire parser downstream. This validator checks a document's well-formedness the same way a real XML parser would, and points you straight at the problem when it isn't.

It's the check to run before debugging why an API call, a config load, or a build step is failing on an XML file you were handed or generated.

What Is XML Validator?

An XML validator (in the well-formedness sense used here) confirms that a document follows XML's structural syntax: every element is properly opened and closed, elements are correctly nested without overlapping, attribute values are quoted, and there's exactly one root element.

This is distinct from schema validation against an XSD or DTD, which checks that specific elements, attributes, and their arrangement match a predefined contract. This tool focuses on the more fundamental question: is this XML at all?

How XML Validator Works

Your input is run through the same stack-based parser used by the Prettifier and Minifier: tags are tokenized, matched against an explicit stack as they open and close, and any mismatch, unclosed tag, or malformed attribute throws an error with the exact character position it occurred at.

That position is converted into a line and column number for display. If parsing succeeds, the resulting tree is walked once to compute element count, attribute count, and maximum nesting depth.

When To Use XML Validator

Use it when a downstream system rejects an XML document and you need to confirm whether the problem is syntax (this tool) or something schema- or business-logic-related (a different tool).

It's also useful as a quick sanity check after hand-editing a config file, before assuming a failure elsewhere in a pipeline is unrelated to a typo in the markup itself.

Often used alongside XML Prettifier, XML Minifier and XML Syntax Highlighter.

Features

Advantages

Runs entirely client-side, so documents with real configuration or customer data never leave your browser.
Reports the exact line and column of a syntax error instead of a generic failure message.
Surfaces useful structural stats (element count, attribute count, depth) for valid documents.
No size limit beyond what your browser can hold in memory.

Limitations

Checks well-formedness only, not conformance to an XSD or DTD schema, and not namespace resolution.
Doesn't validate character encoding declarations or DOCTYPE-specific entity definitions.
Very large files (tens of megabytes) may be slow, since the whole document is held in memory while parsing.

Examples

A well-formed document

Input

<user id="1"><name>Ada</name></user>

Output

Valid XML: 2 elements, 1 attribute, depth 2

The document has a single root element with properly nested and closed children.

An unclosed tag is caught

Invalid input

<root><item>value</root>

Parser error

Unclosed tag <item> at line 1, column 26

The `<item>` element is opened but never closed before `<root>` closes, so the parser reports exactly where it stopped.

Corrected version

<root><item>value</item></root>

A mismatched closing tag is caught

Invalid input

<a><b></a></b>

Parser error

Expected closing tag </b> but found </a>

Elements must close in the reverse order they opened; overlapping tags like this aren't well-formed XML.

Corrected version

<a><b></b></a>

Best Practices & Notes

Best Practices

Validate XML immediately after hand-editing it, before debugging further downstream.
Run this before a schema validator when you're not sure whether a failure is a basic syntax issue or a schema mismatch.
Check the reported depth and element count after generating XML programmatically, as a quick sanity check that nothing was duplicated or truncated.

Developer Notes

This shares the exact parser used by the Prettifier and Minifier (`parseXmlDocument` in the XML category's `lib/xml-core.ts`), so all three tools agree on what counts as well-formed and report identical error positions for the same broken input. Stats are computed with a single tree walk (`collectXmlStats`) rather than during parsing, keeping the parser itself free of validation-specific bookkeeping.

XML Validator Use Cases

Debugging why an API client rejects an XML response
Sanity-checking a hand-edited config file before deploying it
Confirming a programmatically generated XML document has the expected element count and depth
Isolating a syntax error from a schema or business-logic error in a larger pipeline

Common Mistakes

Assuming a document that validates here also conforms to a specific XSD or DTD schema, well-formedness and schema validity are different checks.
Overlapping closing tags (`<a><b></a></b>`) instead of properly nesting them (`<a><b></b></a>`).
Leaving an attribute value unquoted or quoted with mismatched quote characters.

Tips

Use the reported line and column to jump straight to the offending character.
Pair with the Prettifier once a document validates, to make its structure easier to review.
Upload a `.xml` file directly instead of copy-pasting if the document is large.

XML Validator