What Heading Levels Actually Mean

Chapter 05 closed with a question: what’s the difference between an h2 and a div that you’ve made look big? They can render identically. Same font, same size, same weight. To anyone looking at the screen, there is no difference at all.

To everything that isn’t looking at the screen, the difference is the whole point.

Most developers reach for heading elements by size. You need something a bit smaller than the section title above it, so you write <h3>, because h3 looks about right. The next thing down gets <h4>. The logic is visual: pick the level whose default rendering matches the size you want. It’s an easy habit and it’s almost always wrong, because heading levels were never about size.

What the six levels actually are

<h1> through <h6> describe document structure. They mark a hierarchy of topics and subtopics, the same way an outline does.

<h1> is the page’s main topic. There is one of them, and it names what the whole page is about. <h2> elements are the major sections of that topic. An <h3> is a subsection of the <h2> above it. An <h4> is a subsection of that <h3>. The number is a depth, not a font size.

The browser uses this to build a document outline. The clearest way to think about it: take every heading on the page, in order, and indent each one by its level. If the page is structured well, what you get reads as a coherent table of contents.

<h1>Repairing a bicycle puncture</h1>
  <h2>Tools you'll need</h2>
  <h2>Removing the wheel</h2>
    <h3>Front wheel</h3>
    <h3>Rear wheel</h3>
  <h2>Finding the leak</h2>

Read the headings on their own and you understand the page without reading a word of body copy. That is the test. If the outline doesn’t make sense, the markup doesn’t either.

Why this matters to people who can’t see the page

Screen reader users mostly don’t read pages top to bottom. They navigate by headings. In both NVDA and JAWS, the two most common screen readers on Windows, pressing the h key jumps to the next heading, and number keys jump to headings of a specific level. The heading hierarchy is the page’s navigation structure for someone not using a mouse and not seeing the layout.

This changes what a heading is for. It isn’t decoration and it isn’t a size. It’s a landmark. When the structure is right, a screen reader user can move through the page the way a sighted user scans it, skipping to the section they want. When the structure is wrong, that navigation breaks.

Skip from <h1> straight to <h3> with no <h2> between them, and the screen reader announces the jump. The user hears “heading level 3” right after “heading level 1” and has to wonder what they missed. There’s a section in the outline that doesn’t exist. It’s disorienting, and it’s avoidable.

This is covered by WCAG 2.1 Success Criterion 1.3.1, Info and Relationships, which requires that structure conveyed visually is also available in the markup. A heading that looks like a section title but isn’t marked up as one fails that criterion.

Why search engines care too

Search engines read the heading hierarchy as a map of the page’s topics. The <h1> tells them what the page is about. The <h2> elements tell them the major subtopics. This is structural information, not a keyword game. Stuffing terms into headings does nothing useful.

A page where <h1> wraps the site logo and <h2> wraps a decorative pullquote gives a search engine a garbled outline. The headings claim a structure the content doesn’t have. A page whose headings track the actual content hierarchy is simply easier for a crawler to parse, and that clarity is the part that helps.

One h1 per page

HTML5 technically permits more than one <h1> when they sit inside sectioning elements like <article> and <section>. The idea was that each section could restart its own heading scope.

In practice, ignore that. Accessibility guidance and SEO guidance both land in the same place: one <h1> per page, naming the page’s main topic. The sectioning-based outline algorithm was never fully implemented by browsers or assistive technology, so relying on it produces an outline that exists in theory and not in any tool a real user has. Use a single <h1>. Everything else descends from it.

Don’t skip levels going down

The rule for nesting is straightforward. Going down the hierarchy, don’t skip a level: an <h2> can be followed by an <h3>, not jumped straight to an <h4>. Each step down goes one level at a time.

Going back up, skipping is fine. When a subsection ends and the next section begins, you return from an <h4> straight to the next <h2>. That isn’t a gap. It’s the outline closing a branch and starting a new one, which is exactly what should happen.

The semantic level and the visual size are separate things

Here is the part that frees you from picking headings by appearance. The meaning lives in the element. The size lives in the CSS. They are not connected, and you control the connection.

You can make an <h4> render large and an <h2> render small. The <h4> is still a fourth-level heading in the outline a screen reader reads. Visual size and semantic level are two independent decisions, and getting them tangled is what produces heading markup chosen by eye.

The correct relationship runs one direction. Pick the heading level the content’s structure calls for. Then apply a size from the type scale you built in Chapter 01:

/* semantic hierarchy drives the CSS, not the other way around */
h1 { font-size: var(--text-3xl); }
h2 { font-size: var(--text-2xl); }
h3 { font-size: var(--text-xl); }
h4 { font-size: var(--text-lg); }

If a third-level subsection needs to look smaller than the default for h3, change the CSS for that context. Don’t promote it to h4 to borrow a smaller size. The outline has to stay true.

Auditing a page’s headings

You can check any page’s structure without guessing. The DevTools Elements panel shows every heading inline as you scroll the tree, and the accessibility tree view surfaces the heading order the way assistive technology sees it.

Faster than that: the Headings Map extension, available for both Chrome and Firefox, generates a visual outline of the page’s headings and flags level skips directly. Run it on a page you’ve built and you see the document outline the way a screen reader user navigates it. If that outline doesn’t read as a sensible table of contents, the markup needs work before the styling does.

The patterns to watch for

A few specific mistakes show up constantly, and naming them makes them easier to catch in your own work.

Marking every piece of secondary text as <h2> regardless of where it actually sits in the hierarchy. Wrapping the site logo or a nav label in <h1>, when the logo is not the page’s topic. Choosing a level by how it looks, the “make it a bit smaller, use h4” move. And shipping a page with no <h1> at all, which happens most often when the main heading lives inside a hero image and was never set as real text.

Each of these breaks the outline in a way nobody sees until a screen reader reads it back, or a crawler indexes it.

What comes next

Headings give a page its skeleton. The next layer down is the content that hangs off that skeleton: the paragraphs, the lists, the elements that carry the actual prose. Chapter 07 takes on paragraphs and lists, and the semantic choices that matter inside the sections your headings just defined.