HyperText Markup Language
Tool
The language that marks up what a web document contains, so a browser knows a heading from a paragraph before it draws anything.
Why it exists
When documents traveled as plain text, the only reader who could tell a heading from a list item was a human one. People infer structure from blank lines and indentation; machines don't infer. Move a file to another machine and the shape fell apart, and since every group invented its own formatting habits, one document looked ten different ways in ten different places.
The worse gap was that documents had no way to point at each other. A paper that wanted to cite another one printed "see archive document 147," and the reader had to get up and fetch it. Ten references meant ten trips down the hall.
HyperText Markup Language (HTML) was written to close both gaps at once. It labels each chunk of a document as a heading or a paragraph or a list so a machine can act on the label, and it handles pointing at another document with a label of the same kind — one that opens the target when you click it. The hypertext half of the name comes from that second property.
What it solves
HTML solves the problem of a machine not knowing what anything on a screen is. It does it one way: by wrapping content in tags. Put text between an opening and a closing marker — <h1>Pricing</h1> — and those words are now the page's top-level heading rather than a line that merely happens to be large.
Three things follow from the label.
- The browser supplies default behavior. Write a clickable spot as
<button>and the tab key reaches it and the enter key fires it, with no code from you. Build the same shape out of a meaningless box and attach a click handler to it, and every one of those behaviors is yours to write and maintain. - Readers who don't look at the screen can move through the page. A screen reader, the software a blind user listens to, announces "heading level one, Pricing" and offers to jump heading by heading — both driven entirely by the tags. That is where accessibility, designing so the product works regardless of ability or situation, actually begins. Search engine optimization (SEO), the work of shaping a site so it ranks well in results, feeds on the same labels.
- Documents connect.
<a href="/pricing">means "clicking here goes to that address," and one address reaches another company's site as easily as the next page of your own.
So HTML describes identity, not appearance. Making text large and bold is the job of CSS, the style language that specifies how things look; deciding what opens when the text is clicked is the job of JavaScript, the language that creates behavior in the browser. Three languages share one screen and answer three different questions: what is here, how does it look, what does it do.
Alternatives
There are ways to put a screen on the web without HTML, and each one gives up something HTML handed over for free.
The first is painting the screen directly. Browsers offer a blank rectangle you can fill with lines and glyphs pixel by pixel, and products that need that freedom — design tools, maps, games — take this route. The text painted there can't be selected or copied, screen readers can't reach it, and search engines see nothing. To a machine, everything in that rectangle is colored dots.
The second is shipping an installed app. iOS and Android each define screens their own way, with no HTML involved. In exchange you lose the ability to hand anyone a link that just opens, every change waits on review, and the same screen gets built twice.
The third is a simpler markup syntax. Markdown, which marks headings and lists with a few punctuation characters, is the common example. It's far quicker to write, it expresses much less, and browsers can't render it directly — displaying it means converting it to HTML first.
A fourth option gets imagined that isn't one. Modern frontend code rarely contains hand-typed tags; you call functions that produce pieces of a screen, and a file can go from top to bottom without a single angle bracket. What arrives at the browser is still HTML. The writing moved, the format didn't.
How it sounds at work
"Make that a button element instead of a div. It doesn't respond to the keyboard."
It looks like a button but was built as a meaningless box, so the browser won't treat it as one.
"The markup is all divs, so the screen reader can't find a single heading."
The page looks fine and reads as one undifferentiated block of text to anyone not looking at it.
"Search can't pick up this page because the content isn't in the HTML."
The first response is an empty shell that gets filled in later, so the crawler that reads and leaves sees a blank page.
Pagedeck has been through this. Noa was auditing the pricing screen against accessibility criteria and found that all four plan-selection buttons were boxes. Nothing was wrong with a mouse, so nobody noticed for six months, and it surfaced only when a keyboard-only customer wrote in. When Theo switched the tags, the click-handling code someone had written by hand stopped being necessary.
The same week Ravi asked why the new overview page wasn't showing up in search, and the answer sat in the same place. Its heading was styled large instead of being marked as a heading, so the crawler had nothing to read the page's subject from. What the two of them changed wasn't the visible layout — only the labels underneath it.
What people get wrong
The most common mistake is filing HTML under programming languages. Angle brackets and English keywords look like code, developers work in it, and the assumption comes easily. But HTML has no syntax for testing a condition, repeating a step, or computing a value. It states that something is here and that it is this kind of thing. People who miss the distinction plan their learning around it, conclude they're halfway to writing software once they can produce a page, and stall at JavaScript, where the actual difficulty starts.
The other mistake is assuming that easy means sloppy is fine. The syntax is forgiving enough that a missing closing tag still renders something, so nothing tells you it's wrong. What the browser forgives, screen readers and crawlers don't. The feedback also arrives late — it shows up months after launch, in an accessibility audit or in a search-traffic investigation, and by then there are dozens of screens to walk back through.
Easily confused with
| Term | What it is | How it differs from HTML |
|---|---|---|
| Document Object Model (DOM) | The object structure a browser builds from a document so code can work with it | HTML is the text sitting in a file; the DOM is the result of reading that text. Changing the screen doesn't change the original file, which is why developer tools and the source file can show different things |
Where to go next
- Frontend
see the field HTML sits in and what gets used alongside it
- Cascading Style Sheets
the other half of the same screen, handling appearance
- Semantic markup
how to choose tags by meaning rather than by shape
Last updated 2026-09-16