Semantic HTML Explained: header, nav, main and footer

What does "semantic" actually mean in HTML?

"Semantic" comes from *semantics* — the study of meaning. A semantic element carries meaning in its name. <button> means "this is a button". <nav> means "this is navigation". A <div>, by contrast, means nothing at all: it is just a box.

HTML gives you about 100 elements. Roughly a quarter of them are semantic landmarks or content elements: <header>, <nav>, <main>, <article>, <section>, <aside>, <footer>, plus smaller ones like <figure>, <time> and <mark>. The Semantic HTML skill (/skill/semantic-html) defines the goal plainly: use meaningful elements so pages are clearer for browsers, search engines and screen readers. That is the whole point — you are not writing for the browser's *looks*, you are writing for everything that *reads* the page.

Why not just use divs for everything?

Because a page made of only <div>s is a black box. Look at the same page written both ways:

<!-- Everything is a div: only a human reading the class names knows what this is -->
<div class="top">
  <div class="menu">
    <a href="/">Home</a>
    <a href="/about">About</a>
  </div>
</div>
<div class="content">
  <div class="post">...</div>
</div>
<div class="bottom">© 2026</div>

<!-- Semantic: the structure is self-describing -->
<header>
  <nav>
    <a href="/">Home</a>
    <a href="/about">About</a>
  </nav>
</header>
<main>
  <article>...</article>
</main>
<footer>© 2026</footer>

Both versions render identically. The difference is who can *use* the structure:

• A screen reader user can press a key to jump straight to "navigation" or "main content" — but only if those landmarks exist. With divs, they must listen through the whole page in order.
• A search engine weighs content inside <main> and <article> as the page's real content, and treats <nav> and <footer> as supporting structure.
• You, in six months, read the semantic version and instantly see the layout. The div version forces you to decode class names.

Class names are a private agreement between you and your CSS. Semantic elements are a public agreement between your page and the entire web.

What do header, nav, main and footer each do?

These four form the skeleton of almost every page:

Two supporting elements complete most pages:

• <article> — a self-contained piece of content that would make sense on its own: a blog post, a news item, a tutorial summary. An article can have its own <header> (its title) and <footer> (its author/date) — those belong to the article, not the page.
• <aside> — content related to the main content but separable from it: a sidebar, a "related links" box, a pull quote.

A page's skeleton usually looks like this:

<header>...</header>
<nav>...</nav>        <!-- or the nav can live inside the header -->
<main>
  <article>...</article>
  <aside>...</aside>
</main>
<footer>...</footer>

Note that the <nav> often sits *inside* the <header> — that is fine and common. What matters is that navigation links are wrapped in <nav>, not where the <nav> sits.

How do screen readers and search engines actually see this page?

They see the accessibility tree — a simplified version of your page where each semantic element becomes a labelled node. Open Chrome DevTools (F12), go to the Accessibility panel, and inspect a page: a semantic page shows a tree like this:

- banner "Site header"
  - navigation "Main menu"
    - link "Home"
    - link "About"
- main
  - article
    - heading "My first semantic page"
- contentinfo
  - link "Privacy"

A div-only page shows the same content as a flat list of anonymous generic nodes. A blind user navigating by landmarks hears "banner… navigation… main… contentinfo" and can jump directly. On the div version they hear "generic… generic… generic" — or nothing useful at all.

Expected result: build the worked example below, open DevTools → Accessibility, and confirm you see the banner, navigation, main and contentinfo roles. If any region shows as generic, the element there is not semantic.

The worked example: one complete semantic page

Copy this into semantic-page.html, open it in your browser, and check the accessibility tree as described above:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>My first semantic page</title>
  <style>
    body { font-family: system-ui, sans-serif; max-width: 720px; margin: 0 auto; padding: 1rem; }
    nav a { margin-right: 1rem; }
    aside { background: #f5f5f5; padding: 1rem; margin-top: 1rem; }
  </style>
</head>
<body>

  <header>
    <h1>Ada's Notes</h1>
    <nav aria-label="Main menu">
      <a href="/">Home</a>
      <a href="/about">About</a>
      <a href="/contact">Contact</a>
    </nav>
  </header>

  <main>
    <article>
      <header>
        <h2>Why I switched to semantic HTML</h2>
        <p>Published <time datetime="2026-10-24">24 October 2026</time></p>
      </header>
      <p>My pages looked the same, but screen readers could finally navigate them.
         The change took one afternoon and cost nothing visually.</p>
      <footer>
        <p>Filed under: <a href="/topics/html">HTML</a></p>
      </footer>
    </article>

    <aside>
      <h2>Related reading</h2>
      <ul>
        <li><a href="/tutorials/frontend/css-box-model/">The CSS Box Model</a></li>
      </ul>
    </aside>
  </main>

  <footer>
    <p>© 2026 Ada's Notes · <a href="/privacy">Privacy</a></p>
  </footer>

</body>
</html>

How it is built: tags open and close in the right order, the one <main> is a direct child of <body>, the article carries its own <header> and <footer>, and the aria-label on the <nav> gives it a name in the accessibility tree. Expected result: the page renders as a simple centred column with a heading, menu links, the article, a grey "Related reading" box and a footer — and the DevTools Accessibility panel shows the landmark tree from the previous section.

Common mistakes

• More than one <main>. There is exactly one main content area per page. A second <main> — often added around a sidebar — is invalid and confuses assistive technology. Sidebars belong in <aside> inside or beside <main>.
• Wrapping everything in <section> instead of <div>. A <section> needs a heading and a real thematic grouping ("Chapters", "Testimonials"). A box that only exists for styling is still a <div> — that is what <div> is for.
• Using <nav> for every group of links. <nav> is for *major* navigation: the site menu, a table of contents, pagination. A list of social icons in the footer does not need its own <nav> (though it may sit inside the footer).
• Forgetting the one heading rule. Each page should have one <h1> describing the page; sections inside use <h2>, sub-sections <h3>. Skipping levels (<h1> straight to <h4>) breaks the document outline screen readers rely on.
• Putting interactive content where it does not belong. <header> and <footer> must not contain another <header>, <footer> or <main>. The page-level header/footer wrap the page; the article-level ones wrap the article.

Frequently asked questions