HTML for Beginners
HTML describes what content is, not what it looks like. A heading is marked as a heading because it is one; how big and what colour it appears is CSS's job. Getting that split right is most of what separates working HTML from HTML that fights you later.
A complete, valid page is about ten lines:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>My page</title>
</head>
<body>
<h1>Hello</h1>
</body>
</html>
This guide covers the tags you will actually use, the two lines in that boilerplate that people delete without realising what they do, and the semantic choices that decide whether your page works for search engines and screen readers.
The boilerplate, line by line
Every line above is doing something. Two are non-negotiable and frequently omitted.
<!DOCTYPE html>— tells the browser to use standards mode. Leave it out and browsers fall back to a compatibility mode where layout rules behave differently, which produces baffling CSS bugs.lang="en"— declares the language. Screen readers use it to choose pronunciation; search engines use it as a signal. One attribute, real accessibility benefit.<meta charset="utf-8">— how bytes map to characters. Without it, apostrophes, accents and symbols can render as mojibake. Must be near the top of<head>.- The viewport meta — this is the one that matters most. Omit it and mobile browsers render your page at desktop width and shrink it, so everything is tiny and unreadable. No amount of responsive CSS compensates for a missing viewport tag.
<title>— the browser tab, the bookmark name, and the clickable headline in search results.
Head versus body
<head> holds information about the page: title, character set, stylesheets, meta description. None of it is displayed. <body> holds everything the visitor sees.
One more head element worth adding, because it is what search engines show under your title:
<meta name="description" content="A one-sentence summary of this page.">
Text tags
<h1>Page title</h1>
<h2>Major section</h2>
<h3>Subsection</h3>
<p>A paragraph of text.</p>
<strong>Important</strong> and <em>emphasised</em>.
Two rules about headings. Use exactly one <h1> per page — it is the page's title, and having several muddies what the page is about. And do not skip levels: an <h3> should sit under an <h2>, not directly under the <h1>. Screen reader users navigate by heading structure, so a broken hierarchy is genuinely disorienting.
Never choose a heading level because of how big it looks. If you want a smaller heading, keep the correct level and change the size in CSS.
<strong> and <em>, not <b> and <i>. They look the same, but <strong> and <em> carry meaning that assistive technology can convey, while <b> and <i> are purely visual.
Links and images
<a href="https://example.com">Visit example</a>
<a href="/about">About us</a>
<a href="#section-2">Jump to section 2</a>
<img src="chart.webp" alt="Bar chart of monthly sales, rising from January to June">
Link text should make sense alone. "Click here" and "read more" are useless to anyone scanning a list of links, which is exactly how screen reader users navigate. Describe the destination.
Alt text describes the image's purpose, not its appearance. "Bar chart of monthly sales, rising from January to June" is useful; "chart" is not; "image of a chart" is worse. If an image is purely decorative, use alt="" — an empty alt tells assistive technology to skip it, which is correct, whereas omitting the attribute entirely makes it read the filename aloud.
Lists
<ul>
<li>Order does not matter</li>
<li>Bulleted</li>
</ul>
<ol>
<li>First step</li>
<li>Second step</li>
</ol>
Choose by meaning: <ol> when the sequence matters (instructions, rankings), <ul> when it does not.
Semantic structure
Older pages wrapped everything in <div>. Semantic elements say what a region is:
<body>
<header>
<nav>...</nav>
</header>
<main>
<article>
<h1>Article title</h1>
<p>Content...</p>
</article>
</main>
<footer>
<p>© 2026</p>
</footer>
</body>
| Element | Use for |
|---|---|
<header> | Introductory content, site or article header |
<nav> | Major navigation links |
<main> | The primary content — one per page |
<article> | Something that stands alone: a post, a product |
<section> | A thematic grouping, usually with a heading |
<aside> | Related but tangential content |
<footer> | Closing content, credits |
These are not decoration. Screen readers let users jump directly to <main> or list all <nav> regions, and search engines use the structure to work out which part of the page is the actual content. A page built entirely from <div> offers neither.
When to use <div>: when you need a box purely for styling or layout and no semantic element fits. That is a legitimate use — the mistake is using it for things that do have an element.
Forms
<form action="/subscribe" method="post">
<label for="email">Email address</label>
<input type="email" id="email" name="email" required>
<button type="submit">Subscribe</button>
</form>
Every input needs a label, and the for must match the input's id. That pairing is what lets a screen reader announce what the field is for, and it makes the label clickable, which is a genuine usability gain on touch screens.
Use the right type. type="email" gives phone users an email keyboard and basic validation for free; type="number" gives a numeric keypad. Using type="text" for everything throws that away.
Common mistakes
- Missing the viewport meta tag. The single most common reason a page is unusable on a phone.
- Multiple
<h1>elements, or heading levels chosen for size. - Unclosed tags. Browsers guess, and the guess is often not what you meant.
- Styling inside HTML.
<font>and<center>are obsolete; presentation belongs in CSS. - Empty or missing alt attributes on meaningful images.
- Inputs without labels, or a placeholder used as a label — placeholders vanish when you start typing.
Check your work with the W3C validator. It catches unclosed tags and misnesting in seconds, and those are exactly the errors that produce layout problems you would otherwise spend an hour hunting in CSS.
What to learn next
HTML is the structure; CSS is the appearance and layout. Once a page is marked up correctly, the natural next step is positioning things — our guide to centring a div in CSS covers the layout tools and the failure modes that make them confusing.
After that, JavaScript for behaviour: building a unit converter in JavaScript takes a small page from markup to working tool. MDN's guide to structuring content is the reference worth working through properly.
Natural next steps: centring a div in CSS tackles the layout problem everyone hits first, and what is an API covers where the data on a page usually comes from.
Frequently asked questions
What is HTML used for?
HTML marks up the structure and meaning of web content — headings, paragraphs, links, images, forms. It describes what each piece of content is, while CSS controls appearance and JavaScript adds behaviour.
Do I need the DOCTYPE and viewport tags?
Yes, both. <!DOCTYPE html> puts the browser in standards mode, without which CSS behaves differently. The viewport meta tag tells mobile browsers to use the device width — omit it and your page renders at desktop width on phones and appears tiny.
How many h1 tags should a page have?
One. It is the page's main title. Use <h2> and <h3> for sections and subsections, and do not skip levels — screen reader users navigate by that hierarchy.
What is the difference between div and section?
<div> has no meaning and exists for styling and layout. <section> marks a thematic grouping of content and normally has a heading. Use a semantic element where one fits, and <div> only when nothing does.
Should I use strong or b for bold text?
<strong>. It conveys importance that assistive technology can express, whereas <b> is purely visual. The same applies to <em> over <i>.
What alt text should I write for images?
Describe what the image conveys in context, not what it looks like. For a chart, state what it shows. For decorative images that add no information, use alt="" so screen readers skip them — that is different from omitting the attribute, which causes the filename to be read out.
Conclusion
The whole discipline of HTML is choosing the element that matches the meaning of the content. Do that consistently and accessibility, search visibility and maintainable CSS mostly follow.
Start with the ten-line boilerplate, keep the DOCTYPE and viewport tags, use one <h1>, label your inputs, and run the validator when something looks wrong.
Comments