HTML Element Reference

An HTML element reference is a categorized map of every tag the language provides, organized by the job each one does rather than the order you might learn them in. Instead of memorizing tags one at a time, this lesson groups them by purpose — document structure, sectioning, text content, inline semantics, tables, forms, and embedded content — so you can look up "what element should I use for X?" and find the right answer quickly. Even experienced developers keep a reference like this open, because HTML has well over 100 elements and no one remembers all of them from memory.

Overview: How the Reference Is Organized

Every HTML element belongs to one or more content categories defined by the HTML specification: metadata content, flow content, sectioning content, heading content, phrasing content, embedded content, interactive content, and form-associated content. These categories aren’t just academic labels — they determine what is allowed to nest inside what. A browser’s HTML parser uses these rules while building the DOM tree: if you place a block-level sectioning element like a <div> inside a phrasing-content element like <p>, the parser will actually close the <p> early to keep the tree valid, which is a common source of "my markup doesn’t look like I wrote it" bugs.

Semantics matter as much as category membership. Two elements can render identically by default (for example <b> and <strong> both show bold text) yet carry completely different meaning to screen readers, search engines, and other tools that read the DOM rather than the pixels. A reference like this one exists precisely so you pick the element that means what you intend, and let CSS handle how it looks.

Below, elements are grouped the way the HTML Living Standard groups them, with the most commonly used members of each group.

Document & Metadata Elements

Element Purpose
html The root element wrapping the entire document
head Container for metadata not shown directly on the page
title The document title shown in the browser tab
meta Character set, viewport, description, and other metadata
link Links external resources such as stylesheets
body Contains all visible page content

Sectioning & Structural Elements

Element Purpose
header Introductory content or navigation for a page or section
nav A block of primary navigation links
main The dominant, unique content of the page (one per page)
article Self-contained, independently distributable content
section A thematic grouping of content, usually with a heading
aside Content tangentially related to the main content
footer Closing content for a page or section
div A generic block container with no inherent meaning

Text Content & Inline Semantics

Element Purpose
h1–h6 Section headings, in decreasing rank
p A paragraph of text
ul, ol, li Unordered and ordered lists and their items
strong Text of strong importance (typically bold)
em Stressed emphasis (typically italic)
a A hyperlink to another resource
code A short fragment of computer code
span A generic inline container with no inherent meaning
br A single line break within text

Table, Form & Embedded Content

Element Purpose
table, thead, tbody, tr, th, td Tabular data and its rows, headers, and cells
form A section that collects and submits user input
input, label, select, textarea, button Interactive form controls
img An embedded image
video, audio Embedded media playback
iframe An embedded, independent browsing context

Syntax: Reading an Element Entry

When you look up any HTML element — here or in the official specification — you’ll typically see the same shape of information:

<tagname attribute="value">content</tagname>
  • Tag name — the keyword between angle brackets, e.g. article or input.
  • Attributes — name/value pairs inside the opening tag that configure the element (global attributes like id and class work on nearly everything; others are element-specific, like href on a).
  • Content model — what is allowed inside the element (some elements, called void elements, like img and br, can never have content or a closing tag).
  • Closing tag — required for most elements (</tagname>); omitted entirely for void elements.

Examples

Example 1: A Full Semantic Page Skeleton

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Element Reference Demo</title>
</head>
<body>
  <header>
    <nav>
      <a href="#home">Home</a>
      <a href="#about">About</a>
    </nav>
  </header>
  <main>
    <article>
      <h1>Welcome</h1>
      <p>This page demonstrates common structural elements.</p>
    </article>
  </main>
  <footer>
    <p>&copy; 2026 Example Site</p>
  </footer>
</body>
</html>

Result: A page with a top navigation bar containing two links, a main heading and paragraph in the middle, and a copyright line at the bottom. Nothing is styled, so it appears as plain stacked black text on white, but the DOM carries clear structural meaning.

This walks through the most common top-level elements together: header/nav for site navigation, main/article for the primary content, and footer for closing information. A screen reader user can jump directly between these landmarks, which is the real payoff of choosing them over generic divs.

Example 2: Inline Text Semantics

<p>
  To center an element, set its <code>margin</code> property.
  <strong>Do not</strong> forget the closing tag —
  <em>every</em> opened element must be closed.
  See the <a href="https://developer.mozilla.org/en-US/docs/Web/HTML">MDN HTML docs</a> for details.
</p>

Result: A single paragraph renders with the word "margin" in a monospaced font, "Do not" in bold, "every" in italics, and "MDN HTML docs" shown as a clickable blue underlined link.

This shows four different inline elements coexisting in one block of flow content. Each one changes both appearance and meaning: code flags literal code text, strong signals importance, em signals emphasis, and a creates a navigable hyperlink.

Example 3: Table and Form Elements Together

<table>
  <thead>
    <tr><th>Plan</th><th>Price</th></tr>
  </thead>
  <tbody>
    <tr><td>Basic</td><td>$5</td></tr>
    <tr><td>Pro</td><td>$15</td></tr>
  </tbody>
</table>

<form action="/subscribe" method="post">
  <label for="plan">Choose a plan:</label>
  <select id="plan" name="plan">
    <option value="basic">Basic</option>
    <option value="pro">Pro</option>
  </select>
  <button type="submit">Subscribe</button>
</form>

Result: A two-column, three-row table listing plan names and prices appears first, followed by a form containing a label, a dropdown with two options (Basic and Pro), and a "Subscribe" button.

Tables and forms are two of the most structurally strict element families in HTML: a table requires rows made of cells, and a form’s controls must be properly labeled to be usable. This example pairs both families to show how a reference page’s data (the table) and a reference page’s call to action (the form) are built from entirely different sets of elements.

How the Browser Builds the DOM From These Elements

When the browser’s HTML parser encounters your markup, it processes it left to right, token by token, and constructs the Document Object Model (DOM) as a tree of nodes:

  1. The tokenizer reads raw characters and emits tags, attributes, and text as tokens.
  2. The tree construction stage pushes and pops elements onto a stack based on each tag’s content model — for example, seeing a <td> outside a <tr> will cause the parser to auto-insert the missing structural elements rather than fail.
  3. Each element becomes a node in the tree, with attributes attached as properties and text becoming child text nodes.
  4. Void elements like <img> and <br> are added as leaf nodes with no children, since they cannot contain content.
  5. Once the tree is complete, the browser applies default user-agent styles (headings are bold and larger, lists get bullets or numbers, links turn blue) before your own CSS is applied.

Understanding this pipeline explains why invalid nesting doesn’t always throw a visible error — the parser silently repairs many mistakes, which can hide bugs until you inspect the actual DOM in developer tools.

Common Mistakes

Mistake 1: Using a Div for Everything

<div class="nav">
  <div class="nav-link">Home</div>
  <div class="nav-link">About</div>
</div>

This is valid HTML, but it throws away meaning: a screen reader has no idea this is navigation, and the "links" aren’t actually clickable without extra JavaScript. Prefer semantic, native elements:

<nav>
  <a href="/">Home</a>
  <a href="/about">About</a>
</nav>

Result: Visually the two versions can look identical once styled, but only the second is announced as a navigation landmark with real, keyboard-accessible links.

Mistake 2: Nesting Block Elements Inside Inline-Only Elements

<p>
  Here is a list of steps:
  <ul>
    <li>Open the file</li>
  </ul>
</p>

A <p> element only accepts phrasing (inline-level) content, not a list. Browsers will silently close the <p> before the <ul> and reopen a new (invalid, empty) one after it, producing a DOM structure that doesn’t match your source. Keep them as siblings instead:

<p>Here is a list of steps:</p>
<ul>
  <li>Open the file</li>
</ul>

Result: The corrected version renders a paragraph followed by a single bulleted item, with no orphaned empty paragraph in the DOM.

Best Practices

  • Reach for the most specific semantic element available before falling back to div or span.
  • Check an element’s content model before nesting — phrasing elements like p, a, and span cannot contain block-level sectioning content.
  • Use heading elements (h1–h6) in order to build a logical outline, not to achieve a font size — that’s a job for CSS.
  • Always associate form controls with a label using the for/id pair for accessibility.
  • Close every element that requires a closing tag, and never close void elements like br or img.
  • When unsure which element fits, inspect the DOM output of your markup in browser developer tools to confirm the parser built the tree you intended.
  • Bookmark or keep an up-to-date reference (like this one, or MDN’s HTML element index) rather than memorizing every tag — the list is large and occasionally grows.

Practice Exercises

  1. Build a small blog post page using header, main, article, and footer, with at least one heading, two paragraphs, and one link inside the article.
  2. Create a table listing three books with columns for Title and Author, then add a form below it with a text input for searching and a submit button.
  3. Take a page you’ve written that uses several div elements and rewrite it using the most appropriate semantic sectioning elements instead, without changing the visible text.

Summary

  • HTML elements are grouped by content category — sectioning, phrasing, embedded, form-associated, and more — and these categories govern valid nesting.
  • Document and metadata elements (html, head, title, meta) set up the page; sectioning elements (header, nav, main, article, section, footer) structure it.
  • Text-level and inline semantic elements (strong, em, a, code, span) carry meaning distinct from their default appearance.
  • Table and form element families each have strict internal structures that must be followed for the markup to render and function correctly.
  • The browser’s parser silently repairs many invalid nesting mistakes, so always verify your actual DOM output rather than assuming your source order is preserved.
  • Choosing the right element — not just any element that looks correct — is what makes a page accessible, SEO-friendly, and maintainable.