XML Tools

XML Validator

Strict well-formedness checking with the exact line and column of every violation — fix XML errors in seconds.

In short

Validate XML online: check well-formedness with the exact line and column of every error — unclosed tags, bad nesting, illegal characters. Free, private.

By NaveenKumar T · Updated 18 Sep 2026

Learn: XML Namespaces Explained: Prefixes, Default Namespaces and Common Errors

Exact error line & column
Editor error markers
Well-formedness checks

Runs entirely in your browser — nothing you paste or open here is uploaded, logged, or stored.How we handle data →

Example

XML Validator: input and output

A complete, well-formed employee record — the shape Validate should wave straight through.

Input · xml

<?xml version="1.0" encoding="UTF-8"?>
<employee>
  <id>EMP-3390</id>
  <name>Grace Hopper</name>
  <department>Engineering</department>
  <hired_on>2019-03-04</hired_on>
  <active>true</active>
</employee>

Output · xml

<?xml version="1.0" encoding="UTF-8"?>
<employee>
  <id>EMP-3390</id>
  <name>Grace Hopper</name>
  <department>Engineering</department>
  <hired_on>2019-03-04</hired_on>
  <active>true</active>
</employee>

Because the document is already well-formed, Validate reprints it unchanged — that's exactly the signal a valid document is supposed to give you.

Learn more

What makes XML invalid?

The classics: a closing tag that doesn't match the most recent opener (XML demands strict nesting), unescaped & or < inside text, attribute values missing quotes, multiple root elements, and leading whitespace or a blank line before the <?xml?> declaration. Each violates well-formedness and stops every conforming parser cold.

Because this validator reports position precisely — and marks it in the editor — even errors buried in megabyte documents take seconds to locate. Well-formed is not the same as valid; to read the structure a parser produced, the XML parser and XML viewer show the tree.

What a validation error looks like

A real example: an invoice with its closing </invoice> tag typed as </invoic>. The validator reports the exact mismatch — which tag it expected, where that tag was opened, and which tag actually closed instead — rather than a generic "syntax error".

The eight well-formedness rules
Rule	What breaks it	Example
Single root element	More than one top-level element, or none	<a/><b/> at the document root
Matched closing tags	The closing tag's name differs from the opening tag's	<price>10</cost>
Proper nesting	Tags close out of the order they opened	<a><b></a></b>
Quoted attribute values	An attribute value with no quotes	<item id=42>
No duplicate attributes	The same attribute name twice on one element	<item id="1" id="2">
Legal characters in text	A bare & or < inside text content	Price & Tax
Declared or escaped entities	An entity name XML doesn't define	(not a built-in XML entity)
Declaration comes first	Anything — even whitespace — before <?xml …?>	a leading blank line before the declaration

Input — mismatched closing tag

<?xml version="1.0" encoding="UTF-8"?>
<invoice>
  <number>INV-2091</number>
  <customer>Aegis Retail Pvt Ltd</customer>
  <total>18450.00</total>
</invoic>

What the validator reports

Expected closing tag 'invoice' (opened in line 2, col 1) instead of closing tag 'invoic'.
Line 6, column 1

Validating before you ship

Paste any hand-edited config, generated feed, or templated SOAP envelope here before deploying it. A two-second validation catches the broken merge or missing slash that would otherwise surface as a cryptic parser exception in production logs.

Help

Frequently asked questions

Everything you need to know about the XML Validator.

01How do I use the XML Validator?

Paste your XML and click Validate. Valid documents get a green badge and formatted output; invalid ones report the first violation's precise position, underlined in the editor.

02Does this check well-formedness or schema validity?

Well-formedness — the universal layer every XML document must satisfy: matched tags, proper nesting, quoted attributes, legal characters, a single root. Schema validation (XSD/DTD) is vocabulary-specific and requires your schema files; well-formedness errors are what break parsers in practice.

03Why does the validator report "XML declaration allowed only at the start of the document" when the file looks fine?

A leading blank line or stray whitespace before <?xml> triggers this error — something invisible precedes the declaration, often left by a copy-paste from an email or an editor that opens the file with a leading newline. The declaration must be the very first character of the document; even one leading space fails it. Delete everything before the opening <?xml> and validate again.

04How do I validate against an XSD or DTD once this confirms the XML is well-formed?

This page stops at syntax; schema validation needs the schema file plus a tool that understands it. On the command line, `xmllint --schema catalog.xsd catalog.xml --noout` reports every constraint violation; in Java, `javax.xml.validation.SchemaFactory` loaded with the same XSD does the equivalent, and .NET's `XmlReader` with `XmlReaderSettings.Schemas` populated does too. Fix well-formedness errors here first — a broken document fails schema validation for the wrong reason otherwise.

05Why does it stop at the first error instead of listing everything wrong?

A single missing closing tag can shift how the parser interprets everything that follows it, so reporting a dozen consequential errors would bury the one that actually matters. Fix the first violation and re-validate — a second, unrelated problem further down surfaces on the next pass in seconds, since the check re-runs the moment you edit.

Keep working