Elementary Standards
HTMLCSSWeb StandardsSEOBlogStart reading
Home / HTML / The Most Common HTML Markup Errors
HTML

The Most Common HTML Markup Errors

A practical checklist of the markup mistakes that quietly break pages every single day.

7 min read·HTML

This is the archived edition of an earlier essay. The current, expanded version lives at The Most Common HTML Markup Errors.

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.

1. Unclosed and improperly closed tags

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 -->

2. Bad nesting

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 -->

3. Missing alt attributes

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.

4. Duplicate IDs

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.

5. Stray inline styles

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.

The rest of the checklist

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.

Catch them automatically

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.

More on HTML
Keep reading

Related essays