Common causes
1. Different capitalisation
XML names are case-sensitive, unlike HTML. <price> must be closed with </price>, never </Price> or </PRICE>.
<price currency="EUR">129.90</Price><price currency="EUR">129.90</price>2. An element that was never closed
If <name> is left open, the parser expects </name> and reports the parent’s end tag as mismatched. Look for the element named in the “Expected” part of the message.
<item>
<name>Keyboard
<qty>1</qty>
</item><item>
<name>Keyboard</name>
<qty>1</qty>
</item>3. Overlapping elements
Elements must nest completely. <b><i>text</b></i> closes the outer element before the inner one, which HTML browsers tolerate but XML forbids.
<p><b><i>Important</b></i></p><p><b><i>Important</i></b></p>4. HTML void elements written the HTML way
In XHTML, SVG and other XML documents, <br>, <img> and <input> must be closed. Use the self-closing form.
<p>Line one<br>Line two</p><p>Line one<br/>Line two</p>Frequently asked questions
How do I read libxml2's "price line 4 and Price"?
The first name is the element that is still open and the line where it started; the second is the end tag that was found. So the message means “<price> from line 4 was closed with </Price>”.
Why does the error point far below the real mistake?
An element left open is only detected when an end tag for one of its ancestors appears, which can be many lines later. PasteKit names the open element and the line where it started.
Can a parser recover from mismatched tags?
XML parsers must stop at the first well-formedness error. HTML parsers recover, which is why the same markup may display in a browser but fail as XML.