Learn HTML from scratch
HTML is the language of page structure, not a programming language: with it you say this is a heading, this a paragraph, this a list, this a link. To start you need only a text file with an html extension and a browser, and your first page gets built in the first ten minutes.
- Lesson 2 of 12
- Beginner
- Free, no signup
The structure of a page, from root to branches
-
not visible
head
Character encoding, the page title, the mobile viewport setting. Nothing here is printed on the page.
-
visible
body
Everything the user sees lives here, and the next three branches sit inside it.
-
header and nav
The site header and menu. A screen reader can skip the menu, because it knows it is a menu.
-
main
The content unique to this page, one and only one, with the h1 inside it.
-
footer
The site footer: contact, terms, the links repeated on every page.
The browser builds this same structure in memory. Any tag left open closes the branch somewhere else, and the page becomes something you did not write.
Last checked: Facts and tool names in this lesson are re-checked against their sources on this date.
What does HTML do, and what does it not do?
It does one job: it tells the browser what each piece of text is. HTML is short for hypertext markup language, and markup means exactly this labelling: that these few words are the page heading, that this is a paragraph, that those three lines are one list.
Know the three things it does not do, so you do not waste time. Appearance is not HTML work, it is CSS: colour, spacing, size and layout are all decided there. Behaviour is JavaScript: something that opens on click, or a form that submits without a reload. And server side logic is not in the browser at all; storing an order is the job of a program running on the server.
So why does HTML come first? Because it is the only layer all three audiences read: the browser, the screen reader and the search engine crawler. A screen reader does not need your CSS and may never run your JavaScript, but everyone reads the skeleton. Every decision you make in this layer is visible in all three places.
One common misunderstanding ends right here: HTML is not a programming language. It has no conditions, loops or variables, it calculates nothing and decides nothing. It describes. Being simple is exactly why it has lasted.
Your first page: one file, a few lines, a browser
No special software is needed. A plain text editor is enough, even Notepad, and you save the file with an .html extension. Move to a professional editor later; right now it is only in the way.
This is everything a valid page needs:
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>My first page</title>
</head>
<body>
<h1>Hello</h1>
<p>This is the first page I built myself.</p>
</body>
</html>Save the file and double click it; the browser opens it, with no server involved. The first four lines are not there by accident either. doctype tells the browser to use modern rules rather than an old compatibility mode. lang declares the language, and for a right to left language dir declares direction; without them a screen reader reads with the wrong pronunciation. Without charset non-Latin letters break. And without viewport the page shows up shrunken on a phone.
Now change one word and refresh. That short loop, write and look, is the whole method for learning HTML. There is nothing to run or compile.
From an empty file to a page that opens in the browser
-
1
Create a text file
Name it index.html, and make sure the extension really is html, not html.txt.
-
2
Write the skeleton
The doctype, the html tag with language and direction, head and body. That is all.
-
3
Open it in the browser
A double click is enough. No server is involved.
-
4
Change something and look again
Save, refresh, look. That loop is what builds the skill.
-
5
Validate it
Hand the file to the W3C validator so it shows you the unclosed tags.
These five steps run on your own machine and need no hosting or domain. Publishing on the internet is a separate, later stage.
Which element for which job? The semantic skeleton
You can build an entire page out of div elements and make it look exactly the same. What you lose is meaning: a div tells nobody anything, while nav tells a screen reader that this is the site menu and the user can skip past it.
The skeleton almost every page has looks like this:
<body>
<header>
<nav>...</nav>
</header>
<main>
<h1>Page title</h1>
<article>
<h2>A section</h2>
<p>Text.</p>
</article>
</main>
<footer>...</footer>
</body>A few rules hold that skeleton together: one h1 per page and only one, because a page has one main title. Heading levels descend in order, and you never jump from h2 to h4 to get a smaller font; size is CSS work. One main per page, holding the content unique to that page, with the menu and footer left outside it.
For text there are a few small elements that are regularly misused. strong means this is important and em means this word carries stress; if you only want bold or italic with no meaning attached, that is a CSS job. a is where the user goes to another page and button is where something happens on this one. Swapping those two is the most common semantic mistake on the web.
Do not memorise the full list of elements. The MDN HTML elements reference is always open, and someone who has done this for ten years still opens it several times a day.
The same page, with real elements and with empty divs
With semantic elements
- The screen reader says this is the site menu and it can be skipped
- Headings form a real table of contents
- A button works with Tab and Enter, with no extra line of code
- A search engine crawler can tell which piece is the main content
With empty divs
- Everything is one nameless block and there is nothing to skip
- The same job now needs added ARIA attributes
- The button works with a mouse only, not a keyboard
- The structure exists only in the head of whoever wrote the code
Both columns look identical in a browser. The difference shows up where somebody does not see the page and only hears it.
Why accessibility on day one, not later?
Because later is expensive. Build the page with the right elements and a large part of accessibility comes for free; build it out of div elements and try to fix it afterwards, and you have to rebuild the same meaning with extra attributes, which takes longer and breaks more easily.
Four things worth making a habit on day one. First alternative text for images: alt is written for someone who cannot see the picture, so it should say what is going on in it rather than carry a stuffed keyword. If an image is purely decorative, an empty alt="" is correct and leaving alt out is not. Second heading order, which plays the role of a table of contents for a screen reader. Third form labels: every input needs a connected label, otherwise the user hears edit text and has no idea what to type. Fourth keyboard operation: if you cannot reach a button with Tab and activate it with Enter, that thing is not a button, it only looks like one.
One rule sums all of this up and it comes from W3C itself: if a native HTML element exists for the job, use it and do not add ARIA. The Using ARIA document makes that its first rule, and the reason is that wrong ARIA is worse than none: it promises the screen reader something the browser does not do.
Know the boundary too: automated tools do not measure everything. W3C own Easy Checks guidance insists that automatic testing does not replace human review. A machine can tell that alt exists; whether its text really describes the picture is something only you can judge.
Four common mistakes, and how to find them yourself
The first is choosing a heading level by font size. Someone writes h3 because h2 looks too big. The result is a scrambled table of contents for the screen reader and the search engine, when two lines of CSS would have solved it.
The second is a button that is not a button: a div with a click handler. It works with a mouse and not with a keyboard.
The third is meaningless alternative text, like alt="image" or a file name. That is worse than leaving it empty, because it forces the user to listen to something carrying no information.
The fourth is unclosed tags. The browser usually tidies them up and the page looks fine, right until one section suddenly lands inside another and you spend hours hunting for the reason.
Three tools are enough to catch all of these and all three are free. The W3C validator takes your address or your file and shows structural errors line by line; that is where the unclosed tag turns up. The browser developer tools, opened with F12, show the real structure of the page after the browser has interpreted it, and the difference from what you wrote is usually revealing. And the simplest of them, reading the source of other pages: any well built site is a free lesson.
One exercise beats any video: walk through the page you built using the keyboard alone. Just press Tab. Anywhere you get stuck, or cannot tell where you are, you have found a real defect.
The fast path, with AI
Language models write HTML fast and almost always without syntax errors. What they do not do is decide the structure of the page, and that is exactly where the output tends to limp: a heading at the wrong level, a button that is a <code>div</code>, and alternative text written for an image the model never saw. So the fast path is not generate; it is generate and then audit. A fast cheap model is enough here because the work is mechanical; our current pick is in <a class="text-link" href="/en/ai/">the AI section</a>.
- Write the sections of the page on paper, in the order the reader should meet them. This is the one step the model cannot take for you, because it does not know which point matters most.
- Run the recipe below and drop the output into that same index.html file.
- Hand the file to the W3C validator. Clear the structural errors before anything else.
- Check by hand the four things no automated tool can answer: one h1 and the heading order, the alternative text of every image, the label on every form field, and walking the whole page with Tab alone.
- Write the words yourself. Wherever the model left a TODO is your place; text a model writes for an image it never saw is a guess, not a description.
Copy-ready recipe
Role: someone who writes semantic HTML, with no framework and no CSS.
The page I want:
Topic: {page topic}
Sections in order: {list of sections}
Language and direction: {language}, {direction}
Output rules:
- Give HTML only. No CSS, no JavaScript, no library.
- Use the semantic elements: header, nav, main, article, section, footer. Do not use a div while a meaningful element exists.
- Exactly one h1, and heading levels descending in order. Do not pick a heading level for its font size.
- Put lang and dir attributes on the html tag.
- Use button for something that happens on this page, not a clickable div. Use a for going to another page.
- Every input gets a connected label.
- Add no ARIA attribute unless no equivalent HTML element exists. If there is such a place, say why at the end.
- For every image write alt="TODO" instead of invented alternative text, so I can fill it in.
- Write no text, number, name or claim that is not in my input. Leave {...} placeholders instead.
After the code, in three lines, say which structural decisions you made and where you were unsure.Before you trust the output: Do not drop the last step: alternative text for images and the words on buttons are written by a human. The model has not seen your image, and if you force it, it produces a description that reads plausibly and is wrong. Automated auditing is only part of the job too; W3C Easy Checks guidance says exactly that. Nothing replaces the keyboard test and reading the alternative text with your own eyes.
AI in this kind of work
For HTML, AI genuinely speeds the work up, on the condition that you know what to audit. Three uses worth having: producing the first skeleton of a page, explaining an unfamiliar block of code line by line, and turning a div heavy page into its semantic version. Three we do not hand over: deciding the content structure, writing alternative text for images, and judging accessibility.
Tools that actually help
- Claude Good at explaining a block of code line by line and rewriting it semantically. Iran is not on Anthropic supported-countries list; we read that on Anthropic own page.
- Gemini Enough for a first skeleton and basic questions, and it handles Persian well. Google own page says the Gemini web app runs in over 230 countries and territories, and Iran is not on that list.
- ChatGPT The most common choice and acceptable for these jobs. We have no entry for it in our AI section yet, so we make no claim here about its access or pricing.
Where it backfires
The risk here is not syntactic, it is semantic, and it passes quietly. The code a model gives you is usually valid and looks right in the browser, but three things keep coming back: a heading level chosen for appearance, a button that is really a div, and alternative text written for an image the model never saw. A fourth is subtler: extra ARIA attributes that look professional and actually break something. The first rule of W3C own Using ARIA document is exactly that, use the native HTML element where one exists and do not add ARIA. And the Easy Checks guidance says automated review does not replace human review. So our position is simple: generate with the model, audit with a person. For how each tool can be paid for from Iran, see the buying guide.
Sources: W3C: Using ARIA, first rule W3C WAI: Easy Checks Anthropic: supported countries Google: where Gemini Apps are available
Where this advice stops
HTML on its own builds a page, not a site. Layout and appearance are CSS, behaviour is JavaScript, and getting the page to open on the internet is hosting and a domain. More importantly, memorising elements is not the skill; the skill is knowing which element is right for each piece of content, and that only comes from building a few real pages. If your goal is getting a working site up quickly, WordPress or a builder is the shortest route, and this lesson only helps you understand what they produce.
From our own work
The site you are on is our own example and you can read its code. The pages of rgb.ir are built from our own custom theme with PHP files and no page builder plugin is active here, so what you see in view source is what we wrote. On the day this lesson was checked, the front page carried exactly one h1 tag, one main, and twenty six article and fifteen section elements for its content blocks. The one h1 rule and the heading order are not a matter of taste with us either; they are written into the site own writing rules. And one necessary piece of honesty: that same page also has about a hundred and sixty div elements. Writing semantically means using the meaningful element where one exists, not deleting div from the language; for pure layout, div is still the right choice.
Real follow-up questions
Is HTML a programming language?
No. It is a markup language: it describes and does not execute. It has no conditions, loops or variables and calculates nothing. Not being programming is a good reason to start with it.
What software do I need to start?
A text editor and a browser, both already on your computer. After the first few pages an editor like VS Code makes life easier, because it colours the tags and points at the unclosed ones, but you do not need it on day one.
Now that AI writes HTML, is learning it still necessary?
For writing it, no. For reading it, yes. Generated code is usually valid, but somebody has to check its structural decisions; if you do not know what a heading, a button and alternative text should be, you have no way of telling whether the output is correct or merely pretty.