XML mismatched tag: opening and ending tag mismatch

Every XML element must be closed by an end tag with exactly the same name, and elements must close in the reverse order they were opened. The parser met an end tag that does not match the innermost open element. The name comparison is case-sensitive, so <price> and </Price> do not match, and an element left open further up makes every later end tag look wrong.

Seen as:

  • parser error : Opening and ending tag mismatch: price line 4 and Price
  • xml.etree.ElementTree.ParseError: mismatched tag: line 4, column 34
  • The element type "price" must be terminated by the matching end-tag "</price>".
  • System.Xml.XmlException: The 'price' start tag on line 4 position 6 does not match the end tag of 'Price'. Line 4, position 35.
  • XML Parsing Error: mismatched tag. Expected: </price>.

Input

Settings

History

Load from URL

Common causes

1. Different capitalisation

XML names are case-sensitive, unlike HTML. <price> must be closed with </price>, never </Price> or </PRICE>.

Before
<price currency="EUR">129.90</Price>
After
<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.

Before
<item>
  <name>Keyboard
  <qty>1</qty>
</item>
After
<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.

Before
<p><b><i>Important</b></i></p>
After
<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.

Before
<p>Line one<br>Line two</p>
After
<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.

Related