XML Validator

An XML validator answers one question: is this document well-formed? That is different from asking whether it is valid against a schema. Well-formedness is about syntax — one root element, correctly nested and closed tags, quoted attribute values, legal entity references, no stray text outside the root. A document can be perfectly well-formed and still fail an XSD schema; that second check needs the schema document, which a browser-side tool cannot invent.

This validator uses a custom tokenizer and parser written for this site, so the messages are identical in every browser and the position is precise. It is the same engine that powers the XML Formatter and the XML Minifier, which is why a document that validates here also formats and minifies cleanly.

How to validate XML online

1. Paste or load your XML

   Paste into the left editor, or press Load broken sample to see what error reporting looks like before you use it on real data. The pane header shows the input size.

2. Press Validate XML

   The parser reads the whole document before reporting. Errors are collected rather than stopping at the first one, so a single typo does not hide what comes after it.

3. Read the location and the fix

   Each error starts with a line and column, then a sentence explaining what the parser expected and a hint for the usual fix. The code frame underneath marks the exact character.

4. Fix, paste again, repeat

   When the document passes, the result pane shows a structural summary: root element, element count, attribute count, maximum depth, text nodes, comments, CDATA sections and input size.

What well-formed XML requires

Well-formedness is a short list of rules, and almost every real XML failure is a violation of one of them:

• Exactly one root element. Comments and processing instructions may sit around it; elements and text may not.
• Every start tag is closed, either as <tag/> or with a matching </tag>, and nested elements close in reverse order.
• Tag names are case-sensitive. <Item> and </item> are different names.
• Attribute values are quoted with single or double quotes, and an attribute appears only once per element.
• Ampersands and angle brackets are escaped in text — &, <, > — or the text is wrapped in CDATA.
• Only predefined or declared entities are used. XML defines &, <, >, " and ', plus numeric references such as ©.
• Comments cannot contain --, and CDATA sections must end with ]]>.
• The XML declaration, if present, is first — no spaces, BOM or comments before it.

Reading the error report

Errors are printed in source order. Each block contains three things: the location (Line 12, Column 8), the reason (“Closing tag </item> does not match the open <items> tag”) and a fix hint (“XML tag names are case-sensitive”). Under the hint, a code frame shows the offending line with a caret under the column, so even a long line with many attributes is easy to scan.

When the parser has to recover, it shows the most specific error and suppresses follow-on noise. An unterminated comment, for example, produces “Comment is never closed” rather than a second message claiming that every following tag is missing. Up to five errors are displayed per run; fixing them and running again usually surfaces anything that remains.

Common XML errors and their messages

Well-formed vs valid: what this validator does not check

Well-formedness is the syntax layer. Validity is the schema layer: does <price> contain a decimal, is the id attribute allowed here, is the element order correct? Those rules live in an XSD or DTD document, and checking them requires that document too. This page does not fetch or upload schemas — doing so would change both the privacy story and the size limits.

If you need schema validation, xmllint --schema schema.xsd file.xml is the standard command-line answer, and most IDEs have a schema-aware XML plugin. A practical workflow is to check well-formedness here first (fast, no setup), then run the schema check in the build pipeline where the schema already lives.

Namespaces are another thing a pure syntax check cannot settle. The validator accepts prefixes such as <soap:Envelope> as long as the syntax is right; it does not verify that the prefix is declared or that its namespace URI resolves to anything.

What the validation report includes

When the document passes, the report lists the root element, element count, attribute count, maximum nesting depth, number of text nodes, comments, CDATA sections, processing instructions and the exact input size in bytes. That summary is a useful sanity check of its own — a document you expected to contain 400 elements but which reports 4 is suspicious before you ever load it.

The report also counts attributes and text nodes, which helps spot structural surprises: an export that suddenly has zero text nodes, or one that gained a hundred attributes after a schema change, tells you something the raw file does not make obvious.

Large files and privacy

Validation happens in your browser, so a document you check here never leaves the machine. That also means the same 2 MB input cap as the formatter: beyond that, the tab can run out of memory before it finishes. Oversized input is refused with the size and the limit instead of being parsed. For hundred-megabyte files, use xmllint or a streaming parser on the command line; a browser tab is the wrong tool for that job.

Frequently asked questions

Related XML tools