HTML: A Practical Guide

HTML is the markup that gives a web page its structure. Before any styling or scripting, HTML names what each piece of content actually is: a heading, a paragraph, a list, a table, a form, a navigation bar. Browsers, search engines, and screen readers all lean on that structure, so writing good HTML is the first thing that makes a page usable for everyone.

The language is small and forgiving, which is a blessing and a trap. You can get something on screen fast, but sloppy markup quietly hurts accessibility and SEO in ways that do not show up until later. Learn the elements and what they mean, and the rest of the web stack has a solid foundation to sit on.

Open a browser's View Page Source on any flashy site and it collapses into the same dozen tags, just arranged differently. Once you can read the tags, you can read any page on the web, no matter which framework built it.

HTML at a Glance

Category	What it covers	Start here if
Elements & Structure	The document skeleton, headings, text, lists, links, and images	You are building your first page and need the parts in the right order
Tables	Rows, cells, headers, captions, and spanning cells	You have real tabular data and want it readable on a phone too
Forms	Inputs, labels, and a worked poll built end to end	You want something on the page a visitor can actually submit

Where HTML Fits

Every web page is HTML underneath, no matter which framework generated it. React, Astro, and the rest all produce HTML in the end, so knowing the elements helps you read what a tool emits and fix it when the structure is wrong. HTML pairs with CSS for presentation and JavaScript for behavior, but the markup is what holds the meaning.

Open your browser's developer tools on any site and inspect an element. Whatever built the page, a component library, a static site generator, a decades-old content management system, what reaches the browser is HTML. Learning to read that output means you can spot a heading level that jumps from h2 straight to h5, or a button that is really a styled div in disguise, and fix the actual problem instead of patching around it in CSS.

Where HTML Came From

Early web pages were plain text. Tim Berners-Lee added HTML at CERN in 1991 so a document could name its headings, links, and structure, and a browser could follow those links.

The language is still that document format. HTML5 is the current living standard. Browsers parse whatever they are handed and build a tree, which is why a missing tag rarely stops the page and often just rearranges it.

That is why a missing closing tag rarely produces an error and often produces a mystery instead:

<p>First paragraph
<p>Second paragraph

Both paragraphs render, because the parser closes the first one for you when the second begins. Now the same omission somewhere less forgiving:

<div class="card">
  <p>Some text
</div>
<p>Meant to be outside the card

The unclosed paragraph is closed at the div boundary, so this one happens to work. Move a stray unclosed tag inside a table or a list and the repair rules will relocate content somewhere you did not intend, and no error appears anywhere. The page just looks wrong.

Why Semantic Elements Earn Their Keep

Semantic HTML does real work for two audiences you rarely think about while typing tags. A screen reader builds a list of landmarks from elements like nav, main, header, and footer, so a keyboard user jumps straight between them instead of tabbing through every link in order. Wrap everything in generic div elements instead, and that reader sits through the whole page before reaching the part they came for. Search engines lean on the same structure: a page with one clear h1 and a sensible run of h2 and h3 headings hands a crawler an outline it can quote directly in a search result. Div soup, wrapping every piece of content in a plain div regardless of meaning, gives a crawler nothing to grab onto, so hours of writing gets read back as one flat block of text.

The Parser Never Fails

Here is the rule the rest of HTML assumes you already know, and the one that explains most early confusion. An HTML parser does not reject your document. Whatever you hand it, the browser builds a tree of elements, and when the markup does not describe a valid tree the parser repairs it by its own rules rather than stopping.

The practical consequence is worth internalising early. Your styling and your scripts operate on the tree the browser built, not on the file you wrote. When a CSS rule refuses to apply or a script cannot find an element, inspect the tree in developer tools before rereading your markup, because the two are not always the same document.

Why Old HTML Advice Looks Wrong

HTML has been public for three decades and search results remember all of it. A few shapes are worth recognising so you can skip them on sight.

Tables used for page layout. Before CSS could position anything reliably, entire sites were built as nested tables. It works and it is still parsed, but it hands a screen reader a data table where there is no data, and it is why the advice to avoid tables persists past its usefulness. Use tables for genuine tabular data, which is a real and common need, and use CSS layout for arranging the page.

Div soup. Wrapping every piece of content in a plain div was normal when the semantic elements did not exist. They do now, and the elements guide covers which one to reach for.

XHTML habits. Self-closing slashes on void elements and strictly lowercase attributes came from XHTML's XML rules. Neither is required, and neither is wrong, so leave them where you find them and do not treat them as a standard to enforce.

Presentational tags. Advice about b and i being deprecated is out of date; they were redefined rather than removed. The distinction that matters is meaning, and the headings and text guide works through it.

Giving a Document Its Skeleton

Most pages fail their readers before any interesting content arrives, in the outline. A document has a shape: one top-level heading naming the page, sections beneath it in descending order, and landmark elements marking the regions a keyboard user jumps between.

<body>
  <header>...</header>
  <nav>...</nav>
  <main>
    <h1>What this page is</h1>
    <h2>A section of it</h2>
  </main>
  <footer>...</footer>
</body>

Those five elements do work that no amount of styling replaces. A screen reader builds a landmark list from them, so a reader moves to main in one keystroke rather than tabbing through every navigation link first. Heading levels are the other half: they form an outline, and skipping from h2 to h5 because the smaller size looked right breaks it. Size is a CSS decision, and level is a structural one.

Lists, links, and images each carry the same kind of built-in meaning, and each has a way of being written that quietly removes it. The elements and structure guide covers all of them with working markup.

Presenting Real Tabular Data

A table is the right element far more often than the layout-table backlash suggests. Pricing, comparisons, schedules, specifications: anything where a cell means something because of the row and column it sits in belongs in a table, and no arrangement of styled boxes conveys that relationship to a screen reader.

What makes a table readable is header association rather than borders:

<table>
  <caption>Support hours by region</caption>
  <thead>
    <tr><th scope="col">Region</th><th scope="col">Hours</th></tr>
  </thead>
  <tbody>
    <tr><th scope="row">Europe</th><td>09:00-17:00 CET</td></tr>
  </tbody>
</table>

The scope attribute tells assistive technology which header governs which cell, so a reader hears "Europe, Hours, 09:00 to 17:00" instead of a bare time. The caption names the table for someone who cannot see its position on the page. Neither is visible styling and both change what the table means.

Tables are also where phones hurt most, since a wide table either overflows or shrinks to unreadable columns. The tables guide covers structure, headers, captions, spanning cells, and turning a CSV into markup.

Learning Path

Learn HTML in the order that builds a real page:

1. The document structure: doctype, head, body, and metadata.
2. Headings, paragraphs, lists, links, and images.
3. Tables for genuinely tabular data.
4. Forms, input types, and labels that connect to their fields.
5. Semantic elements and landmarks for structure and accessibility.
6. CSS once the markup is solid, then JavaScript for behavior.

Build a small static page once the basics feel normal. A personal profile or a recipe page will teach you structure, links, images, and a form without a framework in the way.

Related Languages

HTML and CSS are a pair: HTML provides the structure and meaning, CSS provides the presentation. Learn HTML first, because there is nothing to style until the markup exists. Then add JavaScript when the page needs behavior, and reach for a framework once plain HTML, CSS, and JavaScript feel comfortable.

HTML and CSS together covers how the two are usually learned as a pair, and which one to start with. Follow the frontend development guide when you want one learning order for HTML, CSS, JavaScript, and TypeScript.

What HTML Cannot Do

HTML describes structure and meaning, and that is the whole of its job. It cannot style itself, so every colour, size, and position decision belongs to CSS. It cannot make decisions or hold state, because it has no variables, conditions, or loops, which is the line that keeps it a markup language rather than a programming one.

It also cannot enforce anything. Form fields carry validation attributes and browsers honour them, but those are a convenience for the person filling in the form, never a guarantee to the server: anyone can bypass them entirely. Validation you actually rely on happens on the server, which is why application security treats browser-side checks as a starting point rather than a defence.

Every Guide in This Section

• Elements and structure is the category hub for the document skeleton and the everyday content elements.
• Document structure covers the doctype, head, body, and the metadata a page needs before anything else.
• Headings and text explains heading levels as an outline and which emphasis element carries which meaning.
• Lists covers ordered, unordered, and description lists, and when each is the honest choice.
• Links and images covers href targets, link text that makes sense out of context, and alt text that earns its place.
• Tables is the category hub for tabular data.
• Table structure covers thead, tbody, rows, and cells.
• Headers and captions covers scope and caption, the two attributes that make a table readable without sight.
• Spanning cells covers colspan and rowspan without breaking header association.
• CSV to HTML table turns exported data into correct markup.
• Add a poll with HTML forms builds a working form end to end.

Related

• CSS handles styling, layout, and responsive design for your markup.
• JavaScript adds behavior once the structure is right.
• Frontend development gives one learning order across the whole front end.
• Programming is the broader language index.

Frequently Asked Questions

Is HTML a programming language?

No. HTML is a markup language that describes structure and content. It has no variables, loops, or conditionals of its own, which is the line usually drawn between markup and programming.

Does HTML support comments?

Yes, written between angle-bracket markers. They stay visible in the page source but are never rendered and never announced by assistive technology, so a comment is not a way to leave a note for a reader.

What is the difference between HTML and XHTML?

XHTML is HTML written to strict XML rules: every tag closed, every attribute quoted, lowercase throughout, and the document must be well-formed or the browser refuses it. Ordinary HTML tolerates the mistakes browsers have always forgiven.

Can you write HTML in any text editor?

Yes, because HTML is plain text. A code editor adds syntax highlighting, tag completion, and error checking that make larger pages faster to get right, but none of that is required to produce a valid file.

Do all browsers render HTML the same way?

Not identically. Parsing rules for standard elements are shared, but default styles, form-control appearance, and support for newer elements differ, which is why testing in more than one browser still matters.

Where to Start

Write one page by hand before reading further. Give it a doctype, a head with a title, and a body holding a header, a nav, a main with a single h1, and a footer. Add two sections with h2 headings, a list, a link, and an image with real alt text, then open developer tools and compare the tree the browser built against the file you wrote. That comparison is the parser rule from earlier made visible, and it is the fastest way to stop guessing. When the page holds together, start with elements and structure and work down the list above.