Semantic HTML, Explained Simply ( What I Learned Today )

Today's lesson on my road to becoming a fullstack developer was all about semantic HTML, courtesy of freeCodeCamp. And honestly? It changed how I look at every web page I've ever built.

Until today, I thought HTML was mostly about making stuff show up on the screen. Wrap things in enough tags, add some CSS, ship it. But today I learned that the tags themselves carry meaning — and using them carelessly has real consequences for accessibility, search rankings, and my own future sanity.

So here are my notes from today, written up as a beginner-friendly guide. If you're learning HTML right now, I hope it gives you a few "aha" moments without the jargon headache.

First, What Does "Semantic" Even Mean?

Semantics is a fancy word for something simple: the meaning of words or phrases in a language. And since HTML is a language too, its elements have their own semantic meaning.

The easiest way to picture this is to think of your HTML document like a text document. A text document has headings, images, bold text, and other formatting — and HTML has elements that represent each of those.

The semantic meaning of an element is the special information that element conveys. A p element, for example, says "this is a paragraph of text":

<p>
  Let me tell you about my fantastic holiday in Paris.
  I saw the impressive Eiffel Tower up close!
</p>

Most elements have semantic meaning. The div element is one of the very few that doesn't — it's just an empty, meaningless box. Using divs isn't a crime (they're still useful for layout!), but as I learned today, leaning on them for everything is a habit worth breaking.

Why Should You Care? Three Big Reasons

Here's where it got interesting for me. Proper semantic HTML isn't about being pedantic — it comes with three very practical benefits:

1. It makes your site work better for people using assistive technology. Screen readers read pages out loud, and they rely on meaningful elements to understand and describe what's on the page. Semantic HTML ensures the best experience for these users.
2. It can improve your search rankings. This is called search engine optimization, or SEO. Search engines crawl your page and use its structure to figure out when and where it should show up in results.
3. It makes development way less painful. Instead of sifting through a pile of divs to find your navigation bar, you can edit the nav element directly and know exactly what you're changing.

Heading Hierarchy: The Part Beginners Get Wrong

The most important part of building a structural hierarchy is using heading elements properly. You know them: h1, h2, h3, and so on. That number is the heading's level, and much like in a text document, you don't want to use them in the wrong order.

Here are the rules I wrote down today:

• h1 is your top-level heading. You'll rarely have more than one per page, and it should typically come before all of your content.
• h2 is your subheading. It always comes after the h1 (sometimes after a bit of introductory text), and unlike h1, you can have multiple h2s on a page. You'll often use them to split your content into sections.
• h3 comes after an h2. You should never skip directly from h1 to h3 — but you can have multiple headings at the same level.

For example, this structure is correct:

<section>
  <h1>freeCodeCamp</h1>
  <h2>Learn Front-End Development</h2>
  <h2>Learn Back-End Development</h2>
</section>

The trap I would absolutely have fallen into: picking a heading element because of its styling — like using h1 just because you want big text. Don't do that. Choose the element that matches your document's structure, and use CSS to get the look you want.

And it really does matter:

• Accessibility: screen readers rely on the structure of a page to decide how to parse and announce it. If a screen reader user hears an h3 right after an h1, they might think they've accidentally skipped over important content, because the h2 is missing.
• SEO: search engines use automation to parse the content of your page and decide when and where it shows up in results. If your structure is malformed, they may not be able to rank you very well in the relevant results.
• Validity: depending on how incorrect your structure is, your HTML may not even be technically valid. When that happens, the browser effectively has to guess what you meant — and what it guesses might not be what you want at all.

Presentational HTML: The Old Way (Please Don't)

Presentational HTML focuses on the appearance and style of content. In the early days of the web, developers used elements like center, big, and font. Modern web development has moved on, and you shouldn't use these types of elements — they come with limitations and a negative impact on accessibility and maintainability.

Many presentational elements are deprecated, which means they're outdated and no longer recommended. There are better ways to get the same results. They mostly still work in browsers (and you'll spot them in old codebases), so it's worth knowing what they look like.

The font element was used to set the font size and color of text:

<font size="5" color="blue">This text is blue and large.</font>

Fun detail: the size attribute ranges from 1 to 7 — 1 is the smallest, 7 is the largest, and 3 is the default if you don't set it. If that sounds arbitrary compared to CSS, that's because it is. Font size and color should always live in CSS, not in your HTML.

The center element was used to center content horizontally within its container:

<center>
  This text is centered.
  <p>HTML is awesome.</p>
</center>

And the big element made text one level bigger than the surrounding text:

<p>
  This text has a normal font size.
  <big>This text is larger.</big>
  Some other text.
</p>

Notice the pattern? All of these elements do a styling job inside the HTML itself. Font sizes, colors, alignment — that's what CSS is for. Keep the two separated and both your page and your future self will thank you.

Semantic HTML: The Modern Way

Semantic HTML is the recommended practice today. Instead of describing how content should look, it describes what the content is. That makes it much easier to read, understand, and maintain.

It also helps the machines that read your page: search engines can easily understand your website, and screen readers get the semantic information they need to describe what's on it.

A few examples of semantic elements from today's lesson:

• header — for defining the header of the document or a section
• nav — for sections with navigation links
• section — for grouping related information
• figure — for illustrations and diagrams

Here's a header element containing a navigation section. Compare it to the div soup most of us beginners write:

<header>
  <nav>
    <a href="#">Home</a>
    <a href="#">About</a>
    <a href="#">Contact</a>
  </nav>
</header>

The purpose of each element is right there in the name — the elements clearly show their role within the structure. And this is just the tip of the iceberg: there are many different semantic HTML elements, and you'll definitely find one that fits the needs of your project.

A Little Cheat Sheet

Here's the quick-reference table I made for myself after the lesson (fittingly, it uses a real table element):

Element	What it means
p	A paragraph of text
h1 – h6	Headings in order of importance — h1 is the top level
header	The header of the document or a section
nav	A section with navigation links
section	A grouping of related information
figure	An illustration or diagram
div	Nothing at all — a generic container with no semantic meaning

My Takeaways from Today's Lesson

A few things I want to remember from today:

• HTML is for meaning, CSS is for looks. The moment I stopped asking "which tag makes this look right?" and started asking "what is this content?", the whole thing clicked.
• Accessibility isn't an afterthought. Someone using a screen reader experiences my page through the tags I choose. That alone is reason enough to do this properly.
• Skipping heading levels is more than a style problem. It actively confuses screen reader users and search engines — it's not just untidy.
• "It works" isn't the same as "it's right." Deprecated elements still render in browsers, but that doesn't make them a good idea.
• Personal mission: stop using div for everything. If something is a navigation bar, it deserves to be a nav.

That's it for today's notes. Nothing flashy — but it's exactly the kind of fundamental that separates "I can make a page show up" from "I can build a page properly." On to the next lesson.