Error Unclosed and mismatched HTML tags
Why unclosed and out-of-order closing tags break HTML parsing, and how the HTML5 error-recovery algorithm papers over them.
This covers two related issues the validator reports: a closing tag with no matching opener (orphan-closing-tag), and a tag that is opened but never explicitly closed, or closed in the wrong order (unclosed-tag).
Why it happens
HTML elements are meant to nest strictly — whatever opens last must close first. A stray </div> with no matching <div>, or a <div><span>text</div></span> where the closing tags are swapped, both break that nesting.
Example
<!-- Wrong: closing tags out of order -->
<div><span>Hello</div></span>
<!-- Right -->
<div><span>Hello</span></div>Void elements like <img>, <br>, and <input> never need a closing tag — the validator does not flag those. A handful of elements (<li>, <p>, <td>, and similar) have optional closing tags under the HTML spec's tag-omission rules, so the validator does not flag those either.
Why it matters
Browsers do not reject malformed nesting outright — the HTML5 parsing spec defines a precise error-recovery algorithm that decides how to "fix" broken markup. The result is deterministic per browser, but it is rarely what you intended, and older or non-browser HTML consumers (feed readers, scrapers, some templating tools) do not implement the same recovery rules and can produce different output entirely.
Frequently asked questions
Does invalid tag nesting break my page visually?
Usually not immediately — browsers apply the HTML5 error-recovery algorithm and render something. But the resulting DOM structure can differ from what you wrote, which shows up later as CSS that targets the wrong element or JavaScript that queries the wrong node.
Do I need to close every tag?
No. Void elements (img, br, hr, input, meta, link, and a few others) are never closed. A handful of elements like li, p, and td have optional closing tags under the HTML spec — the parser infers where they end.