HTML: structure and meaning

Let's start with something fundamental: HTML is not a programming language. It performs no calculations, makes no logical decisions and cannot do arithmetic. HTML stands for HyperText Markup Language.

Its only job is to “mark up” plain text so it can tell the browser: “This piece is a heading, this sentence is a paragraph, and this element is a button”.

When you write an HTML file and open it, the browser reads it and builds a tree structure called the DOM (Document Object Model). Picture it as a branching set of boxes: the main box contains smaller boxes, which in turn contain text or further boxes. CSS and JavaScript will later act on exactly this tree. Without solid HTML they would have nothing to style or animate.

Now that we have a sense of how the browser organises information into boxes (the DOM), let's build our first box. To do that, we start from HTML's basic building block: the tag.

To give a web page structure, HTML uses tags — literally, labels. Imagine you have some plain text and you want to tell the browser: “This piece of text is a paragraph, while this other one is a heading”. To do that, you stick a label before and after the text.

These labels are written between angle brackets (the less-than < and greater-than > symbols) and, in most cases, always work in pairs:

• The opening tag (the start): marks where our element begins. You write the label's name between the angle brackets. To start a paragraph, for instance, we use <p> (the “p” stands for paragraph).
• The content: everything enclosed between the opening and closing labels (the paragraph's text, for example).
• The closing tag (the end): tells the browser where the element finishes. It is identical to the opening one but contains a forward slash / placed straight after the first angle bracket, like this: </p>. Think of the slash as a stop sign.

These three parts together (opening tag + content + closing tag) form what is known as an HTML element.

Tags can also carry attributes: extra pieces of information placed exclusively inside the opening tag. Attributes specify an element's characteristics or behaviour (a link's destination, an image's source) and are always written in the form attribute-name="value" — a key="value" pair.

Let's look at a link (the <a> tag):

In this example:

• The key (the attribute's name) is href, which tells the browser: “I want to set a destination web address”.
• The value is "https://codedge.it" (always in quotation marks after the equals sign =), which defines the specific web address.

A few rare tags contain no text and enclose nothing, so they need no closing tag. These are called empty tags (or self-closing tags). Examples are <img> for showing an image and <br> for a line break.

The nesting rule

In HTML, putting one tag inside another is called nesting. Picture the structure as a set of Russian dolls: a smaller box has to sit entirely inside a bigger one.

There is one very simple golden rule that keeps you from ever getting it wrong:

To grasp this easily, think of the brackets you use when writing by hand. If you open a round bracket ( and then a square one [, you must close the square one first and the round one after. You cannot cross them like this: ( [ ) ].

Let's compare the wrong structure with the right one directly.

<p>This text is <strong>very important.</p></strong>

<p>This text is <strong>very important.</strong></p>

Modern browsers do their best to “fix” nesting errors on their own, but making them do so slows them down and forces them to guess your intentions. That often leads to unexpected visual bugs, problems on mobile devices, or difficulties for people using screen readers.

Now that you know how to write a single tag, how to set attributes and how to fit boxes inside one another without mistakes, let's put all the pieces together. In the next chapter we look at the starting skeleton shared by every web page that exists.

In the previous chapters we covered HTML's theory: how the browser thinks as it builds the tree (the DOM) and the rules for writing individual tags correctly. Now let's take a step forward and combine those ideas to build our first real file.

Every web page needs a fixed starting structure before the browser can interpret it. That repetitive structure — a genuine blank canvas — is known as the boilerplate. In VS Code you can type ! and press Enter to generate it instantly, but as good developers we should understand every single line of it:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>My first web page</title>
  </head>
  <body>
    <!-- The site's visible content goes here -->
  </body>
</html>

How the structure is organised:

• <!DOCTYPE html>: a technical declaration. It shouts at the browser: “Careful, this is a modern HTML file (HTML5), read it using current standards!”. It must be written as the very first line, at the top.
• <html lang="en">: the root box containing everything else. The lang="en" attribute matters a great deal: it declares that the text is in English, which helps search engines index it and lets screen readers pronounce it with the right intonation.
• The split into two main areas: notice how the content inside <html> is divided into two big nested boxes:
  • <head> (the control room): holds the metadata — information useful to the browser and to Google but invisible to visitors (the UTF-8 character encoding for accented letters and emoji, or the tab's title in the <title> tag).
  • <body> (the visible stage): the page's body. Everything we put in this block appears on the user's screen.

Now that your empty container is set up, it is time to go inside the <body> and start exploring the catalogue of tags: the actual bricks we will fill our page with. We begin with the foundation of any communication: writing text.

What is the <body> tag?

The <body> tag is, to all intents and purposes, your website's visible canvas. Everything a user sees, reads, clicks or interacts with inside the browser window — text, headings, images, video, buttons, navigation menus, contact forms — must go inside this box, without exception.

To see why it matters, think of a paper letter:

• The <head> is the envelope: it carries the recipient's address, the stamp, the sender. Essential information for getting the letter delivered, but nobody reads the envelope to find out the message.
• The <body> is the sheet of paper inside: the actual message, the written words, the drawings or the enclosures. It is what the reader actually cares about.

There are three golden rules to keep in mind whenever you work with the <body>:

Now that it is clear what this space is and why it exists, let's start filling it. We begin with by far the most common case: text.

Why “bare” text is not enough

The instinctive first move is to write the text straight inside the body, breaking lines where needed:

<body>
  HTML course
  This is the first sentence.
  This should be a separate sentence.
</body>

Open this file in a browser and you will see one thing, all on a single line:

HTML course This is the first sentence. This should be a separate sentence.

That is not a bug. It is the most important rule to understand about text in HTML:

This means the page's appearance does not depend on how you format the code, only on which tags you use. The indentation in the file is there for you to read, not for the browser. To genuinely separate two blocks of text, you need tags.

The paragraph: <p>

The <p> tag (paragraph) encloses a complete block of text. Each paragraph takes its own line, breaks by itself, and the browser leaves a little space above and below it.

<body>
  <p>This is the first sentence.</p>
  <p>This is a separate sentence, in a block of its own.</p>
</body>

Now the two texts really are two distinct blocks. Note that inside a paragraph you can lay the text out however you like, across several lines in the code: it will still be one block, because it is the tag that defines the block, not the line break.

Headings: from <h1> to <h6>

A long text made only of paragraphs is unreadable: you need to break it into sections with headings. HTML provides six heading tags, from <h1> to <h6>.

The number does not indicate the font size: it indicates the depth level, exactly like the numbers in a table of contents. <h1> is the title of the whole page, <h2> opens a main section, <h3> a sub-section of that section, and so on.

<h1>Cookery course</h1>
<p>Welcome to the course. Here is what we will cover.</p>

<h2>The equipment</h2>
<p>Before cooking you need the right tools.</p>

<h3>Knives</h3>
<p>Three are enough to get started.</p>

<h3>Pans</h3>
<p>Better a few good ones than many poor ones.</p>

<h2>The first recipes</h2>
<p>Let's start with something simple.</p>

The tags you see written describe this structure, which is the page's table of contents:

Cookery course                  [h1]  ← the page's title
 │
 ├── The equipment              [h2]  ← section
 │    ├── Knives                [h3]  ← sub-section
 │    └── Pans                  [h3]  ← sub-section
 │
 └── The first recipes          [h2]  ← section

This hierarchy is not just theory: Google uses it to understand how content is structured, and screen readers use it so that blind users can orient themselves and jump quickly from one section to another.

The three rules of headings

• One <h1> per page. It is the document's title, so there is only one, like the title of a book.
• Do not skip levels. After an <h2> you can use an <h3>, not an <h4> directly: it would leave a hole in the outline.
• Choose the level by logic, never by how big it looks on screen. The browser gives headings a default size purely for convenience: you will change that size with CSS, without touching the tag.

Headings and paragraphs establish a page's overall frame. Often, though, you need to highlight or give special meaning to individual words or phrases inside a paragraph (to mark an important term or a fragment of code, say) without breaking the line. That is the job of inline tags, which we look at in the next chapter.

In the previous chapter we used tags that create whole blocks of text and break the line automatically (paragraphs <p> and headings). Inline tags, by contrast, go directly inside a piece of text. They highlight or define one or more specific words without breaking the line or interrupting the paragraph's flow.

<p>Remember: the <code>&lt;title&gt;</code> tag is <strong>mandatory</strong> on every page.</p>

The sentence stays a single sentence: <strong> and <code> do not create a new block, they mark up part of existing text.

The inline tags you will actually use

<p>
  <abbr title="HyperText Markup Language">HTML</abbr> was born in
  <time datetime="1991">1991</time>. The formula for water is
  H<sub>2</sub>O and the price is <del>£20</del> <ins>£15</ins>.
</p>

<strong> or <b>? <em> or <i>?

<b> and <i> also exist, and on screen they give exactly the same result (bold and italic). They have not been removed from the standard, but they mean something different: they mark text as visually distinct without attaching importance to it (a scientific name in italics, say, or an article's keywords in bold).

Breaking lines for real: <br> and <hr>

We said that pressing Enter in the code does not break the line. When the line break is part of the content — a postal address, the lines of a poem — you use the empty tag <br>:

<p>
  Codedge Ltd<br>
  12 Roma Street<br>
  00100 Rome
</p>

The <hr> tag, also empty, marks a thematic break between two parts of the content (the browser draws it as a horizontal line). Same principle: if all you want is a decorative line, use CSS.

Writing special characters: entities

What if you want to display the < symbol itself on screen? The browser would think you were opening a tag. That is why HTML entities exist: sequences beginning with & and ending with ;.

Accented letters and emoji need no entities: the file just has to declare <meta charset="UTF-8">, as in the boilerplate from chapter 3.

Comments

You can leave notes in the code that the browser ignores entirely, by wrapping them in <!-- and -->:

<!-- Offers section: update every Monday -->
<p>20% off the whole catalogue.</p>

By now you have used tags that take a whole line and tags that stay inside the line. That difference is not accidental: it is the classification the whole of HTML rests on. Let's look at it.

Why do two <p> elements end up one below the other, while two <strong> elements sit side by side on the same line? Because every HTML element belongs, by default, to one of two categories.

Block elements

• They always start on a new line and push whatever follows onto the next one.
• They take up the full available width of their container, even when the content is short.
• They can contain other blocks and inline elements.

Blocks include: <p>, <h1>…<h6>, <div>, <ul>, <ol>, <li>, <table>, <form>, <figure>, <hr>, <header>, <nav>, <main>, <article>, <section>, <aside>, <footer>.

Inline elements

• They do not break the line: they flow within the line of text alongside the words.
• They take up only the space of their content, not a millimetre more.
• They must contain text or other inline elements, never a block element.

Inline elements include: <a>, <strong>, <em>, <code>, <span>, <img>, <br>, <abbr>, <input>, <label>.

Try this example: the two paragraphs stack, the two <span> elements stay together.

<p>First block: I take the full width.</p>
<p>Second block: I sit below the first.</p>

<p>
  <span>First inline.</span>
  <span>Second inline: I am on the same line.</span>
</p>

Why you need to know this now

Because this distinction is where the most frequently broken nesting rule comes from:

There is one very important exception to this rule: the link tag <a>, although an inline element, can enclose whole blocks (headings, paragraphs, entire <div> elements). That is essential for making a whole area or a product card clickable, rather than just its text:

<a href="/products/mug/">
  <h3>Codedge mug</h3>
  <p>Glazed ceramic, 350 ml.</p>
</a>

You know how tags are written and how they are laid out. One cross-cutting piece is missing: the attributes you can put on any tag, which the coming chapters will use constantly.

So far we have seen attributes that only work on certain tags: href, for example, makes sense on a link but not on a paragraph. HTML also provides global attributes (or universal ones): attributes you can write on any element.

The two most important are id and class, and both do the same job: giving an element a label so you can find it again later. The only difference is how many times that label may appear on the page:

• id: like a student's registration number. It belongs to one single element: two elements on the same page cannot share an id.
• class: like saying “the students in class 3A”. It can be repeated on as many elements as you like, and an element can belong to several classes at once.

1. The id attribute: a unique name

id assigns a name identifying a single element on the page. You write it like any other attribute, inside the opening tag:

<h2 id="contact">Where to find us</h2>
<p>We are at 12 Roma Street, open Monday to Friday.</p>

What is a unique name good for?

• In HTML: for creating links that jump to a specific point on the page (anchors, which we will see in the next chapter) and for tying a form's label to its input.
• In CSS: for styling that one element.
• In JavaScript: for reaching that specific element and changing it, in response to a click for instance.

2. The class attribute: a group label

class groups elements under a common category. The same class can appear on as many elements as you like:

<p class="notice">Shipping is running normally.</p>
<p class="notice">Last day to order!</p>
<p>This paragraph has no classes: it is not part of the group.</p>

An element can also belong to several groups at once: just write the names separated by a space. That is not “one class with a space in it”, it is two distinct classes:

<p class="notice urgent">Deliveries suspended today.</p>

What is grouping good for?

• In CSS: for giving every element in the group the same appearance by writing the rule once.
• In JavaScript: for acting on every element in the group with a single instruction.
• For whoever reads the code: a name like product-card says at a glance what role that element plays.

Other useful global attributes

Besides those two, there are others you will meet often:

For instance, if you drop a phrase or a quotation in another language into an English page, it is good practice to flag it like this:

<p>The company's motto is <span lang="it">chi va piano va sano</span>.</p>

That way the screen readers used by people with visual impairments will pronounce the phrase in Italian, rather than reading it as if it were English.

Now that you know how to give an element an id, we can tackle the tag that turned the web into a web: the link.

The hyperlink is what turns isolated pages into a site, and sites into a web. You create one with the <a> tag (anchor) and its href attribute (hypertext reference), which gives the destination.

<a href="https://codedge.it">Go to the Codedge site</a>

The text between the two tags is the visible, clickable part; href is the address, which the user does not see. An <a> without an href is not a link: it is just text.

The possible destinations

Relative paths, explained once and for all

This is where everyone trips up. Imagine this folder structure on your computer:

site/
├── index.html          ← the home page
├── about.html
├── images/
│   └── logo.png
└── blog/
    ├── index.html      ← the blog's home page
    └── first-post.html

A relative path is read starting from the folder holding the page you are writing. The ../ symbol means “go up one folder”.

Opening in a new tab

The target="_blank" attribute opens the destination in a new tab, leaving the starting page open.

<a href="https://github.com" target="_blank" rel="noopener noreferrer">
  Open GitHub in a new tab
</a>

The rel="noopener" attribute stops the destination page manipulating the originating one via JavaScript; noreferrer also avoids telling it where the visitor came from. Recent browsers apply noopener themselves with target="_blank", but writing it remains the right habit and covers older browsers.

Writing good link text

Screen reader users can ask for a list of every link on the page, read out of context. A list of twelve “click here” entries is unusable.

Link text should describe its destination even when read on its own. That is the accessibility rule for links, and it doubles as good SEO practice.

Your pages now talk to each other. Let's add visual content.

Images are inserted with <img>, an empty tag: it encloses nothing and has no closing tag, so all the information travels through attributes.

<img src="/images/cat.jpg"
     alt="Ginger cat asleep on a grey sofa"
     width="800" height="600">

Writing the right alt

The alt attribute is read by screen readers, appears if the file fails to load, and is used by search engines. There is no absolutely “right” text: it depends on the role the image plays on the page.

• The image carries information → describe the information: alt="Chart: sales up 30% in 2025".
• The image is inside a link or a button → describe the destination, not the picture: alt="Back to the home page", not alt="logo".
• The image is purely decorative → leave the attribute empty: alt="". The screen reader then skips it, instead of reading out the file name.
• The text is already written next to the image → alt="", so the same thing is not announced twice.

Why you should give width and height

The browser draws the page before it has finished downloading the images. If it does not know how much space to reserve, it lays the text out and then makes it jump when the image arrives: that is the irritating layout shift that loses your place on the page. Give the file's real dimensions and the space is reserved immediately.

Which format to choose

• WebP / AVIF: today's default choice. The same quality as JPEG and PNG in much lighter files.
• JPEG: photographs, where maximum compatibility matters.
• PNG: images with a transparent background, or flat-colour graphics.
• SVG: logos, icons and diagrams. A vector format: it stays sharp at any size and weighs almost nothing.

An image with a caption: <figure>

When an image has a caption, do not put it in an ordinary <p>: there would be no connection between the two. Use <figure> to group them and <figcaption> for the caption.

<figure>
  <img src="/images/client-server-diagram.png"
       alt="The browser sends a request to the server, which responds with the page"
       width="600" height="400" loading="lazy">
  <figcaption>Figure 1 — The request/response cycle between client and server.</figcaption>
</figure>

The caption describes the image for people who can see it; alt replaces it for people who cannot. They are two different texts with two different purposes: do not copy one into the other.

Video and audio

Video and audio work the same way, with the controls attribute showing the playback controls:

<video src="/media/demo.mp4" controls width="640" poster="/media/preview.jpg">
  Your browser does not support video. <a href="/media/demo.mp4">Download the file</a>.
</video>

The text inside the tag appears only if the browser cannot play the file. The poster attribute gives the image to show before playback starts. Avoid autoplay: a video that starts by itself with sound is the fastest way to get the page closed.

Text and images are sorted. Let's move on to organising information into lists.

Lists are for whenever you have several items of the same kind. Not just bullet points: navigation menus, product galleries and search results are all, underneath, lists. Marking them as such tells screen readers how many items are still to come.

Unordered list: <ul>

For when the order of the items does not change the meaning. The container is <ul> (unordered list), each entry is an <li> (list item).

<ul>
  <li>Flour</li>
  <li>Sugar</li>
  <li>Eggs</li>
</ul>

Ordered list: <ol>

For when the order matters: instructions, rankings, steps. The browser handles the numbering; you do not write the numbers.

<ol>
  <li>Heat the oven to 180 °C</li>
  <li>Mix the ingredients</li>
  <li>Bake for 40 minutes</li>
</ol>

On <ol> you can use start="5" to begin from a different number, reversed to count backwards and type="a" to number with letters.

Lists inside lists

This is where the most common mistake hides. The child list goes inside the <li> it belongs to, not between one <li> and the next:

<ul>
  <li>Drinks
    <ul>
      <li>Water</li>
      <li>Wine</li>
    </ul>
  </li>
  <li>Desserts</li>
</ul>

Description list: <dl>

For term/explanation pairs: glossaries, FAQs, spec sheets. The container is <dl>, the term is <dt>, the description is <dd>.

<dl>
  <dt>URL</dt>
  <dd>The unique address of a resource on the web.</dd>

  <dt>DOM</dt>
  <dd>The tree the browser builds as it reads the HTML.</dd>
</dl>

A <dt> can have several <dd> elements (one term with several meanings), and several <dt> elements can share a <dd> (synonyms).

The practical case: a navigation menu

A menu is a list of links. Written this way, a screen reader announces “list of 3 items” and lets the user skip the whole thing.

<ul>
  <li><a href="/en/">Home</a></li>
  <li><a href="/services/">Services</a></li>
  <li><a href="/en/contact/">Contact</a></li>
</ul>

The bullets and the vertical stacking are removed with CSS: looking like a horizontal bar is a visual choice, while the list remains the correct structure.

Lists organise data in one dimension. When there are two dimensions, you need tables.

A table is for tabular data: information that only makes sense where a row and a column meet. A price list, a train timetable, a comparison of subscription plans.

The full structure

<table>
  <caption>2026 subscription plans</caption>
  <thead>
    <tr>
      <th scope="col">Plan</th>
      <th scope="col">Monthly price</th>
      <th scope="col">Storage</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Basic</th>
      <td>£9.99</td>
      <td>10 GB</td>
    </tr>
    <tr>
      <th scope="row">Premium</th>
      <td>£14.99</td>
      <td>100 GB</td>
    </tr>
  </tbody>
</table>

The attribute that makes a table accessible

Someone looking at a table crosses row and column with their eyes. Someone listening to it cannot: they hear the cells one after another. The scope attribute on each <th> solves this by saying whether that header applies to a column (scope="col") or to a row (scope="row").

With scope set, the screen reader says “Premium, monthly price: 14.99 pounds” instead of a list of numbers with nothing to anchor them. Two words per cell, and the usability changes completely.

Merging cells

colspan stretches a cell across several columns, rowspan across several rows:

<tr>
  <td colspan="2">This cell spans two columns</td>
  <td>Normal</td>
</tr>

Use them sparingly: tables with too many merged cells become hard to read and hard to announce correctly.

You have now learned all the content building blocks. The question becomes: how do you group them? Let's start with the containers that mean nothing, so we can see why the ones that do mean something matter.

Every tag we have seen so far says something: <p> is a paragraph, <ul> is a list, <th> is a header. Two of them say nothing at all, and that is exactly why they exist.

• <div> is a block container with no meaning.
• <span> is an inline container with no meaning.

You will recognise the distinction: it is the one from chapter 6. A <div> behaves like a <p> (breaks the line, takes the full width), a <span> like a <strong> (stays within the line).

What they are for

Grouping elements so you can hook something onto them — nearly always a class for CSS, sometimes an id for JavaScript — when that grouping has no meaning of its own to convey.

<div class="product-card">
  <h3>Codedge mug</h3>
  <p>Glazed ceramic, 350 ml.</p>
  <p>Price: <span class="discounted-price">£12.90</span></p>
</div>

The <div> exists only to give CSS something to grab hold of when drawing the card's frame, background and borders. The <span> exists only to colour the price red. Remove the CSS and the page reads exactly the same: they are containers with zero meaning.

The mistake to avoid: “divitis”

Because <div> always works and never errors, the temptation is to build the whole page out of it:

<div class="header">
  <div class="nav">...</div>
</div>
<div class="main">
  <div class="article">
    <div class="title">How to write HTML</div>
    <div class="text">...</div>
  </div>
</div>

On screen, with the right CSS, this page can look identical to a well-written one. But to anything without eyes it is a field of anonymous boxes: the browser does not know what the main content is, Google cannot tell where the article begins, and a screen reader can offer no shortcuts because there is nothing to announce. Note too that <div class="title"> is not a heading: it appears in no document outline, whereas an <h1> does.

The next chapter gives you the tags to look for before falling back on <div>.

HTML5 provides a set of tags that behave exactly like a <div> — they are block containers — with one decisive difference: they declare the role of the part of the page they enclose.

The structural tags

A complete page

Here is how they fit together. Compare this structure with the field of <div> elements from the previous chapter: the on-screen result can be the same, the information conveyed is not.

<body>
  <header>
    <h1>The Codedge blog</h1>
    <nav>
      <ul>
        <li><a href="/en/">Home</a></li>
        <li><a href="/blog/">Blog</a></li>
        <li><a href="/en/contact/">Contact</a></li>
      </ul>
    </nav>
  </header>

  <main>
    <article>
      <h2>How to write clean HTML</h2>
      <p>Published on <time datetime="2026-03-14">14 March 2026</time>.</p>

      <section>
        <h3>Start from the structure</h3>
        <p>Content first, styling second.</p>
      </section>

      <section>
        <h3>Choose the right tags</h3>
        <p>Every tag has a meaning: use it for that.</p>
      </section>
    </article>

    <aside>
      <h2>Related articles</h2>
      <ul>
        <li><a href="/blog/css-basics/">Introduction to CSS</a></li>
      </ul>
    </aside>
  </main>

  <footer>
    <p>&copy; 2026 Codedge</p>
  </footer>
</body>

<article>, <section> or <div>?

This is the recurring question. Answer these three in order:

1. Would this block make sense published on its own, detached from the rest of the page (in an RSS feed, shared on social media)? If yes → <article>.
2. Otherwise: is it a thematic part with a heading of its own? If yes → <section>.
3. Otherwise: it exists purely for the styling → <div>.

The concrete benefit: navigation shortcuts

<header>, <nav>, <main>, <aside> and <footer> are landmarks: reference points that screen readers list on request. A blind user can jump straight to the main content instead of listening to the menu again on every page of the site. With <div> elements that possibility simply does not exist.

The same principle applies to keyboard users. By making the first element of the <body> a link pointing at the <main>, you offer the same shortcut:

<a href="#content" class="skip-to-content">Skip to content</a>
...
<main id="content"> ... </main>

The page is structured and readable. One last thing it cannot do: receive something from the user.

Until now the page speaks and the user listens. With forms the flow reverses: searches, logins, sign-ups, orders and comments all go through here.

The <form> container

<form action="/signup" method="post"> ... </form>

• action: the address the data is sent to.
• method: how it is sent. get appends it to the URL, leaving it visible in the address bar: fine for a search, which is then shareable and bookmarkable. post sends it in the request body, outside the URL: mandatory for passwords, personal data and anything that changes something on the server.

The fields: <input> and its type

<input> is an empty tag that changes appearance and behaviour completely according to its type attribute:

Choosing the right type is not pedantry: on its own it gives you the right keyboard on mobile, a validity check and, for dates, a calendar you did not have to program.

Every field needs a <label>

A field without a label is an empty box whose purpose nobody knows. The label is connected to the field by matching its for with the field's id:

<label for="email">Email address</label>
<input type="email" id="email" name="email">

The connection has two effects: the screen reader announces “email address, text field” when the user reaches it, and clicking the label moves the cursor into the field, widening the clickable area — a real benefit on a touchscreen.

The name attribute: the most important of all

When the form is submitted, every field sends a name = value pair. The name comes from the name attribute: it is the key the server uses to find the data.

The other fields

• <textarea>: multi-line text. It is not an input, it has a closing tag, and the initial value is written between the two tags.
• <select> with <option>: a dropdown menu. Each option has a value attribute, and that is what actually gets sent.
• <button>: the button. Inside a form the default type is submit: if you need a button that sends nothing, write type="button" explicitly.
• <fieldset> with <legend>: groups related fields and gives the group a name. Indispensable with radio buttons, since otherwise it is unclear which question they answer.

Validation that needs no code

The browser already knows how to reject an incomplete or malformed form, without a line of JavaScript:

These checks improve the user's experience, but they must always be repeated on the server: anyone can bypass the browser's validation.

A complete form

<form action="/contact" method="post">

  <label for="name">Full name</label>
  <input type="text" id="name" name="name" required autocomplete="name">

  <label for="email">Email</label>
  <input type="email" id="email" name="email" required
         placeholder="name@example.com" autocomplete="email">

  <label for="reason">Reason for getting in touch</label>
  <select id="reason" name="reason">
    <option value="info">Request for information</option>
    <option value="quote">Quote</option>
    <option value="support">Support</option>
  </select>

  <fieldset>
    <legend>How would you prefer to be contacted?</legend>

    <input type="radio" id="by-email" name="contact" value="email" checked>
    <label for="by-email">By email</label>

    <input type="radio" id="by-phone" name="contact" value="phone">
    <label for="by-phone">By phone</label>
  </fieldset>

  <label for="message">Message</label>
  <textarea id="message" name="message" rows="5" required></textarea>

  <input type="checkbox" id="privacy" name="privacy" required>
  <label for="privacy">I have read the privacy policy</label>

  <button type="submit">Send request</button>

</form>

Look at the two radio inputs: they have different id values (which must be unique) but the same name. It is that shared name that makes them alternatives to each other: change it and they become two independent choices the user can select at the same time.

The <body> can now do everything. Let's return to the top of the file, where you decide how the page presents itself to the world.

In chapter 3 we defined the <head> as the document's invisible part. It does not hold what you read on the page, but everything needed in order to read it: how to interpret the characters, how to behave on phones, which stylesheets to load, what to show on Google and in chat apps.

The three lines you cannot do without

<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>HTML course for beginners | Codedge</title>

• charset: declares the character encoding. Without it, accents and emoji turn into gibberish. Write it among the very first lines of the head.
• viewport: tells the phone to use the screen's real width. Without this line the phone pretends to be a desktop and shows the page shrunk down and unreadable.
• title: the browser tab's title, the bookmark's name and the blue title in search results. It is different from the <h1>, which lives in the body: keep it under 60 characters.

Getting found: metadata for search engines

<meta name="description" content="A practical guide to HTML: structure, semantic tags, links, images and forms explained step by step.">
<link rel="canonical" href="https://codedge.it/en/tutorials/html-fundamentals/">

• description: the roughly 150-character summary that appears under the title in search results. It does not directly affect ranking, but it decides whether anyone clicks.
• canonical: gives the page's official address. If the same content is reachable from several URLs, it stops it being treated as duplicate.

The preview when a link is shared

When you paste an address into WhatsApp, LinkedIn or Slack and a card appears with a title, a description and an image, that data comes from the Open Graph metadata. If you do not write it, the preview will be a bare link or a random crop of the page.

<meta property="og:title" content="HTML course for beginners">
<meta property="og:description" content="Structure, semantics, links, images and forms explained step by step.">
<meta property="og:image" content="https://codedge.it/images/preview.jpg">
<meta property="og:url" content="https://codedge.it/en/tutorials/html-fundamentals/">
<meta property="og:type" content="article">

Linking CSS and JavaScript

The head is also where you declare the external files the page needs:

<link rel="stylesheet" href="/css/style.css">
<script src="/js/app.js" defer></script>

The stylesheet goes in the head because it is needed before the page is painted. For scripts, the defer attribute tells the browser to download them in parallel and run them only once the page is ready: you avoid blocking rendering and you make sure the elements you want to manipulate already exist.

The head is rounded out by the tab icon: <link rel="icon" href="/favicon.ico">.

A head you can copy

<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">

  <title>Page title | Site name</title>
  <meta name="description" content="A summary of the page in about 150 characters.">
  <link rel="canonical" href="https://example.com/page/">

  <meta property="og:title" content="Page title">
  <meta property="og:description" content="A summary of the page.">
  <meta property="og:image" content="https://example.com/preview.jpg">
  <meta property="og:url" content="https://example.com/page/">

  <link rel="icon" href="/favicon.ico">
  <link rel="stylesheet" href="/css/style.css">
</head>

You have now seen the whole path: from the file's skeleton to the content tags, from semantic structure to forms, right through to the metadata. Before moving on to practice, let's look at the mistakes worth avoiding from the outset.

To close on a practical note, here is a round-up of the mistakes beginners make most often, and the advice for fixing them straight away.

Here are the essential semantic tags to remember for structuring content correctly:

There is no better way to learn than getting your hands dirty. Try this small challenge in the playground or in your own editor before moving on to the quiz:

You have laid the foundations of your house on the web. Now that you have the structure under control, you can start decorating it and making it smart. Here are the natural next stops on your learning path:

• CSS fundamentals: the logical next step, for adding colour and style and defining the spatial layout of your HTML tags.
• VS Code essentials: learn to write code quickly using Emmet shortcuts, automatic suggestions and the ideal working environment.
• Browsers and DevTools: find out how to inspect the DOM, explore a page's elements in real time and diagnose bugs.
• All tutorials: back to the full list, to pick your next topic.