XML parsing errors

An element was closed out of order: the parser met an end tag for an ancestor while a child was still open, so the tree cannot be built at all.

The document ended while one or more elements were still open — almost always truncation, not an authoring mistake.

Something follows the root element — a second root, a stray closing tag, or a fragment that was never a whole document.

A bare & appeared in content. XML reads it as the start of an entity reference and expects a name and a semicolon.

An HTML entity was used in XML. Only five are predefined; anything else must be declared in a DTD or written as a numeric character reference.

What arrived is not XML — an HTML error page, a JSON body, or plain text served under an XML content type. The parser found no opening tag.

Whitespace precedes the XML declaration. A single blank line, or one space, before it is enough to make the document not well-formed.

An attribute value is not quoted. XML requires quotes around every value, including numbers — unlike HTML, which accepts bare values happily.

The same attribute name appears twice on one element, which XML forbids outright. HTML silently keeps the first; XML refuses the document.

An attribute value was opened with a quote that is never closed, so the parser runs past the end of the tag looking for the matching one.

An element name breaks XML's naming rules — usually because it starts with a digit, contains a space, or uses punctuation XML reserves.

Nothing arrived at all. Almost always a transport problem — a 204, a dropped connection, or a fetch that succeeded against the wrong URL.

The declaration names an encoding the parser cannot decode — a typo, a vendor-specific label, or a charset the build of libxml2 was not compiled with.

The three characters ]]> are reserved as the CDATA terminator and cannot appear literally in element content, even outside a CDATA section.

A comment was opened with <!-- and never closed, so the rest of the file is swallowed as comment text and the reported line is the end, not the fault.

Two declared entities refer to each other in a cycle. The parser stops rather than expand forever — the same guard that blocks a billion-laughs attack.

A raw control character reached element content. XML 1.0 forbids most of them, and no escaping makes them legal — they must be removed at the source.

A literal < inside an attribute value. XML forbids it there because the parser cannot tell it from the start of a tag, so it must be written &lt;.

A numeric character reference points at a code point XML does not allow — usually &#0; or another control character that escaping cannot make legal.

Two parts of the XML declaration ran together with no space between them. Terse enough to be baffling, and it always means the same thing.

The document opens with <?xml but no version attribute. Version is the one part of the declaration that is not optional, and it must come first.

The declaration names an XML version that does not exist. There are only two — 1.0 and 1.1 — and in practice you want 1.0 unless you know otherwise.

A processing instruction was opened with <? and never closed with ?>. Everything after it is consumed as instruction data until the file runs out.

A CDATA section was opened and never closed with ]]>, so the rest of the document — closing tags included — was read as literal text inside it.

A start tag was never closed with >, so the parser kept reading and found the next element's markup where an attribute name should have been.

XML forbids -- inside a comment's body, even when the comment is otherwise closed properly. It is one of the specification's genuinely surprising rules.

A numeric character reference was opened with &# and never closed with a semicolon, so the parser read past the digits into text that is not a number.