The browser is famously forgiving. Feed it broken HTML and it patches the wound, builds a DOM, and shows something. That mercy is precisely why bad markup survives to production — it never announces itself. Here is a field guide to the errors I see most, why each one bites, and how to catch it before your users do.
A forgotten </div> is the classic. The parser guesses where the element ends, and its guess rarely matches yours — later content gets absorbed into the wrong container, and your layout collapses for no visible reason.
<div class="card">
<p>Content
<!-- oops: no closing div, next section is now inside .card -->Elements have content models. A block-level <div> inside a <p>, or an <li> that is not a child of <ul> or <ol>, is invalid. The parser “corrects” it by silently closing your paragraph early — and now your CSS selectors miss.
<p>Intro <div>box</div></p> <!-- p is closed before the div -->Every <img> needs an alt. Meaningful images get a description; purely decorative ones get an empty alt="" so screen readers skip them. Omitting the attribute entirely leaves assistive tech to announce the file name — hero-final-v3-USE-THIS.jpg — which helps no one.
An id must be unique in the document. Duplicate it and fragment links jump to the wrong place, getElementById returns only the first match, and <label for> associations break. This one is invisible until a form or an anchor misbehaves.
A style attribute here and there feels harmless, then multiplies into an unmaintainable mess that overrides your stylesheet through specificity you cannot easily beat. It also complicates a Content Security Policy. Move it to CSS.
&, <, and > in text, not the raw symbols.lang. Set <html lang="en"> so screen readers pronounce correctly.<title>. Required, and it is your tab and search-result label.bgcolor, align, border — all belong in CSS now.<label>.<h1> with no structure. Use a sane heading order, not size-picking.The browser hiding your mistakes is not the same as your mistakes being harmless. It just means the bill arrives later, addressed to someone using a screen reader.
You will not spot these by squinting. Run the Nu Html Checker in your build, add an accessibility linter, and treat validation warnings the way you treat compiler warnings — as a to-do list, not background noise. Correct markup is cheaper to write than to debug.