An unescaped ampersand
Input
<company>Ben & Jerry</company>
Result
An "&" must start an entity such as &. Line 1, column 15.
Write it as Ben & Jerry. The same applies to a literal < inside text.
XML Tools
XML Validator
Check whether an XML document is well formed, with the line, column, and cause of the first error.
Start here Paste the exact document, including the XML declaration if there is one.
- Elements
- 8
- Attributes
- 6
- Nesting depth
- 4
- Text characters
- 92
Well formed means the syntax parses. It does not mean the document matches a DTD or an XML Schema, which is a separate check against a contract.
Understand the format
How XML Validator works
Well formed and valid are two different checks, and most "invalid XML" errors are really the first one: the document does not parse at all.
Well formed is not the same as valid
A well-formed document obeys the syntax of XML: one root element, every tag closed, tags properly nested, attribute values quoted, and reserved characters escaped. Any XML parser can check this without knowing anything about your data. That is the check this page performs.
A valid document is well formed and also matches a declared contract, a DTD or an XML Schema, which says which elements may appear, in what order, with which attributes and data types. A document can be perfectly well formed and still be rejected by a service because an element is missing or a date is not a date. Checking syntax first is worth the ten seconds, because it removes an entire class of confusing failures.
Reading the position of an error
The line and column reported here point at the first place the grammar was broken, which is often slightly after the real mistake. An unclosed element is a good example: the parser only discovers the problem when it meets a closing tag that does not match, or when the document ends. Read the position as a starting point and scan backwards for the nearest unbalanced tag.
Documents copied from a terminal or a log viewer bring their own failure modes: a truncated tail, a byte-order mark before the declaration, smart quotes substituted by an editor, or an ampersand in a customer name that was never escaped.
The five entities XML actually defines
XML predefines only & < > " and '. Everything else, including the that HTML authors reach for by reflex, must be declared in a DTD or written as a character reference such as  . An undefined entity makes the document not well formed, which is why a stray stops a whole feed from parsing.
A bare ampersand is the same mistake in a different disguise. "Ben & Jerry" inside an element is a syntax error; it has to be "Ben & Jerry". This is by far the most common cause of a document that looks fine to a human and fails on the first parse.
Step by step
How to use XML Validator
- Paste the exact document, including the XML declaration if there is one.
- Read the banner: green means the syntax parses, red reports the first violation with its line and column.
- Use the caret under the offending line to find the character the parser stopped at.
- Fix that one problem and check again, rather than making several speculative edits at once.
- When it is well formed, check the element and attribute counts against what you expected.
Validation runs entirely in your browser using a parser written for this site, which means malformed data, internal element names, and copied payloads stay on your machine.
Worked examples
XML Validator examples explained
Overlapping tags
Input
<b><i>text</b></i>
Result
Closing tag </b> does not match the open element <i>.
XML requires strict nesting. HTML browsers forgive this; XML parsers never do.
Reference
The rules a document must follow to be well formed
| Rule | Breaks it | Correct |
|---|---|---|
| Exactly one root element | <a/><b/> | <root><a/><b/></root> |
| Every element is closed | <a><b></a> | <a><b/></a> |
| Tags nest, never overlap | <b><i></b></i> | <b><i></i></b> |
| Element names are case sensitive | <Note></note> | <note></note> |
| Attribute values are quoted | <a id=1/> | <a id="1"/> |
| An attribute appears once per element | <a id="1" id="2"/> | <a id="1"/> |
| & and < are escaped in text | <a>Ben & Jerry</a> | <a>Ben & Jerry</a> |
Practical Guide
How teams use XML Validator
Common use cases
- Find why a supplier feed, SOAP response, or config file will not parse.
- Check a document by hand after editing it, before feeding it back into a pipeline.
- Confirm the shape of a document, element and attribute counts and nesting depth, against what you expected.
Checks before trusting the result
- A green result proves syntax only, never that the document satisfies a schema.
- Check the encoding declared in the XML declaration matches how the file was actually saved.
- Watch for invisible characters, especially a byte-order mark, before the declaration.
Troubleshooting
Common mistakes and how to fix them
- Using or another HTML entity.
- XML defines only five entities. Use a character reference such as  , or declare the entity in a DTD.
- Treating a well-formed result as approval from the receiving system.
- Follow it with schema validation against the DTD or XSD the service publishes.
- Different case on the opening and closing tag.
- XML element names are case sensitive, so <Note> and </note> are different elements.
- A declared encoding that does not match the file.
- If the declaration says UTF-8 but the file was saved as Latin-1, accented characters will fail to parse. Re-save as UTF-8.
FAQ
XML Validator questions, answered
What is the difference between well formed and valid?
Well formed means the syntax is correct and any parser can read it. Valid means it also matches a declared DTD or XML Schema. This page checks the first; a schema validator checks the second.
Does this validate against my XSD?
No. Schema validation needs your schema and is normally done in your own build or service, where the schema is versioned alongside the code.
Why does my document fail on an ampersand?
Because a bare & starts an entity reference. Any literal ampersand in text or in an attribute value has to be written &.
Can XML have more than one root element?
No. Exactly one element contains everything else. If you are producing a stream of records, wrap them in a single container element.
Is an empty document well formed?
No. A document must have a root element, so an empty file or a file containing only a comment fails.
Is my document uploaded for checking?
No. The parser runs in this page, so supplier feeds and internal payloads never leave your machine.
Go deeper
Specifications and guides
- JSON Debugging Workflows for API Teams — A practical guide to formatting, validating, and diffing payloads before they hit production.