Common XML errors and how to fix them
When a parser says your XML is “not well-formed”, it means the document breaks one of a small set of structural rules. The good news: nearly every broken XML file fails for one of the ten reasons below. Here’s what each looks like and how to fix it.
To find the failure instantly, paste your document into ourXML validator — it underlines the exact line and column and explains the error in plain English. These rules apply to every XML dialect: SVG, RSS, Atom, XSD, WSDL, sitemaps, Maven POMs, Android layouts.
1. Mismatched tags
Every element must close in the reverse order it opened — XML nesting is strict, unlike lenient HTML parsers that silently recover.
<!-- ✗ Invalid — <b> closes after its parent -->
<a><b>text</a></b>
<!-- ✓ Valid -->
<a><b>text</b></a>Parsers report the location where the closing tag didn’t match — but the real mistake is often an earlier tag that was never closed. Check the element the parser says it “expected” first.
2. Unclosed elements
An element that opens and never closes makes everything after it part of its content, and the error surfaces only at the end of the file. If the element is genuinely empty, use the self-closing form:
<!-- ✗ Invalid — never closed -->
<br>
<!-- ✓ Valid — self-closing -->
<br/>This bites people converting HTML to XHTML or SVG: HTML void tags like<br>, <img>, and <input> must be written <br/>, <img/>, <input/> in XML.
3. The bare ampersand
& starts an entity reference in XML, so a literal ampersand must be written&. URLs with query strings are the classic offender:
<!-- ✗ Invalid — "&page=2" is not an entity -->
<link>https://example.com/search?q=xml&page=2</link>
<!-- ✓ Valid -->
<link>https://example.com/search?q=xml&page=2</link>The same applies to a literal < in text, which must be<. Our XML escaping guide covers all five predefined entities and when you actually need them — and theXML formatter can escape bare ampersands for you in one click.
4. Unquoted or mis-quoted attribute values
Every attribute value must be wrapped in matching single or double quotes. HTML tolerateswidth=100; XML does not.
<!-- ✗ Invalid -->
<img width=100 alt="logo'/>
<!-- ✓ Valid -->
<img width="100" alt="logo"/>Watch out for “smart quotes” (” “) pasted from Word or chat apps — they look right but are not quote characters to a parser.
5. Duplicate attributes
An element may not carry the same attribute twice:
<!-- ✗ Invalid -->
<user id="1" id="2"/>This usually appears after a sloppy merge or a search-and-replace. Keep the value you meant and delete the other.
6. Multiple root elements
An XML document must have exactly one top-level element wrapping everything else.
<!-- ✗ Invalid — two roots -->
<user>…</user>
<user>…</user>
<!-- ✓ Valid — one wrapping root -->
<users>
<user>…</user>
<user>…</user>
</users>You’ll hit this when concatenating XML fragments — say, records exported one at a time — into a single file. Wrap them in a container element.
7. Case mismatches
XML is case-sensitive: <User> and <user> are two different elements, so <User>…</user> is a mismatched-tag error. HTML forgives this; XML never does. Pick one casing convention (lower-case or camelCase) and stick to it.
8. Problems before the first tag
Two rules about the very start of the file trip people up:
- The XML declaration (
<?xml version="1.0"?>), if present, must be the first bytes of the document — no blank line, no comment, not even a space before it. - The declared encoding must match reality. A file declared
encoding="UTF-8"but saved as Windows-1252 will fail on the first accented character with an “invalid byte” error. Re-save the file as UTF-8.
9. Undeclared namespace prefixes
A colon in a tag name marks a namespace prefix, and the prefix must be bound to a URI by anxmlns: declaration on that element or an ancestor. Copy a fragment out of a WSDL or an Atom feed without its root element and the binding is left behind:
<!-- ✗ Invalid — prefix "dc" was never declared -->
<item><dc:creator>Ada</dc:creator></item>
<!-- ✓ Valid -->
<item xmlns:dc="http://purl.org/dc/elements/1.1/">
<dc:creator>Ada</dc:creator>
</item>The URI is only an identifier — nothing is fetched from it and it need not resolve. Typing it incorrectly produces no well-formedness error at all; the document simply belongs to a different namespace than you intended, which surfaces much later as a schema mismatch.
10. Invalid characters and invalid names
Two rules about what may appear where. Element and attribute names must start with a letter or underscore and may not contain spaces — <2fa> and<first name> are both errors, which is why converting JSON with arbitrary keys into XML so often fails.
Separately, XML 1.0 forbids most control characters (U+0000–U+001F) outright, even when written as numeric references. Only tab, line feed, and carriage return are permitted. A stray NUL or ESC byte from a database dump or a log file makes the document unparseable, and because the character is invisible your editor shows you a line that looks perfectly fine. A validator reporting an exact column is the only practical way to find it.
When the error is not where the parser says
The single most frustrating property of XML errors is that the reported line is where the parser gave up, not where you made the mistake. An element left unclosed on line 40 swallows everything after it, and the complaint arrives at line 4,000 or at the end of the file. Three techniques narrow it down quickly:
- Format the document first. Broken nesting usually becomes visible as indentation that never comes back to the left margin.
- Read the “expected” element name. When a parser says it expected
</section>and found</body>, the unclosed element is the<section>— search backwards for its opening tag. - Bisect. On a large file, delete the second half and re-validate. If it still fails, the problem is in the first half; if it now passes, restore and cut the other way. Five or six rounds isolates almost any error in a document of any size.
Well-formed is only half the story
Everything above concerns well-formedness — the universal grammar every XML document must follow. A well-formed document can still be invalid against a schema (DTD or XSD) that dictates which elements and attributes are allowed where. Fix well-formedness first; schema validation only runs on a document that parses at all.
Find your error in seconds
Paste your document into the Indentio XML validator. Each problem is underlined at its exact line and column with a plain-English reason, and theformatter re-indents the fixed result while preserving your comments and CDATA. Everything runs in your browser — nothing is uploaded.