Skip to content

What is HTML

docs.scrimba.com

Every website you have ever visited starts as a plain text document written in HTML. The headings, paragraphs, buttons, images, and links you see on a page are all described in this one language. Before you can style a page or make it interactive, you describe what is on it, and that description is HTML.

A page is just structured text

HTML stands for HyperText Markup Language. The important word is markup: HTML is a way of taking plain text and marking up which parts are headings, which are paragraphs, which are links, and so on. You are not giving the computer instructions to follow. You are labelling content so the browser knows what each piece is and how to show it.

Think of it like formatting a document by hand. You circle the title, underline the section headings, and draw a box around a photo. HTML is how you do that circling and underlining in a way a browser understands.

HTML is a declarative language: you describe the structure you want, not the steps to produce it. There is no logic, no loops, no variables. You state "this is a heading, this is a paragraph, this is a list of three items", and the browser is responsible for turning that description into something on screen.

This is why HTML is not a programming language in the usual sense. It does not compute anything. It structures content. That distinction matters once you add CSS and JavaScript, because each of the three has a job it is good at, and HTML's job is structure.

HTML is a declarative markup language that the browser parses into a tree of objects called the DOM (the Document Object Model: the live, in-memory representation of the page that CSS styles and JavaScript manipulates). Your source text is the input; the DOM is what the browser actually renders and what every other web technology talks to.

That framing explains a lot of HTML's behaviour. HTML parsing is deliberately forgiving: a missing closing tag or a misnested element rarely throws an error, because the parser follows a defined recovery algorithm and builds a valid tree anyway. This is a feature, not sloppiness. It kept two decades of imperfect pages working. It also means "it renders" is a weak test of correctness: the browser will construct a DOM from almost anything, so structuring your markup well is on you, not the parser.

html
<h1>Welcome</h1>
<p>This is a paragraph of text on my first web page.</p>

Two lines, two pieces of structure: one heading and one paragraph. The browser reads the labels and shows the first line large and bold, the second as ordinary body text.

JunoA page is just structured text HTML is how you label the parts of a page so the browser knows what they are. You are not writing instructions, you are marking up content: this bit is a heading, this bit is a paragraph. That is the whole idea, and everything else builds on it.
JunoA page is just structured text HTML is declarative: you describe structure, the browser handles the rest. No logic lives here, which is exactly why it pairs with CSS and JavaScript. Keep HTML's job clear in your head and the other two get easier to place.
JunoA page is just structured text The browser parses your markup into the DOM, and that tree is what everything else acts on. Parsing is forgiving by design, so it renders proves almost nothing. Well-formed structure is your responsibility, and it pays off the moment CSS and JavaScript start reading the tree you built.

Elements, tags, and attributes

Most of HTML is made of elements. An element usually has an opening tag, some content, and a closing tag:

html
<p>Hello there.</p>

<p> is the opening tag, </p> is the closing tag (note the slash), and "Hello there." is the content in between. Together they make a paragraph element. The tags are the labels; the content is what the visitor reads.

You can also give a tag extra information with an attribute. A link needs to know where it goes, so you tell it with an href attribute:

html
<a href="https://scrimba.com">Visit Scrimba</a>

An element is an opening tag, its content, and a closing tag. Attributes go inside the opening tag as name="value" pairs and configure the element: href on a link sets its destination, src on an image sets its file, alt sets the fallback text.

html
<a href="https://scrimba.com" target="_blank">Visit Scrimba</a>

Some elements have no content and no closing tag. These are void elements: <img>, <br>, <input>, <hr>. They carry everything they need in their attributes, so there is nothing to wrap and nothing to close.

The vocabulary is worth getting exact, because people use it loosely and it causes confusion later. A tag is the text you type, <p> or </p>. An element is the whole thing the parser produces: the tags plus their content plus any descendants. An attribute is a name="value" pair on the opening tag that sets a property of the element.

Void elements (<img>, <input>, <br>, <hr>, <meta>, <link>) have no content model and therefore no closing tag; the trailing slash you sometimes see (<br />) is optional in HTML and has no effect, a holdover from XHTML. Attribute values are strings, even when they represent numbers or booleans: disabled is a boolean attribute whose mere presence is true, and <input value="5"> holds the string "5" until something reads it as a number. Knowing that the DOM is stringly-typed at this layer saves you a class of bugs when JavaScript starts reading attribute values back.

JunoElements, tags, and attributes An element is an opening tag, some content, and a closing tag, like <p>...</p>. Attributes go in the opening tag and add details, like where a link points. Do not worry about memorising every tag. You will learn them a handful at a time as you need them.
JunoElements, tags, and attributes Tags are the text, the element is the whole thing, attributes configure it. Watch for void elements like <img> and <input>: no content, no closing tag, everything lives in the attributes. Getting the vocabulary right now makes the rest of the docs read cleaner.
JunoElements, tags, and attributes Tag, element, and attribute mean three different things, and keeping them straight pays off when you debug. Attribute values are strings at this layer, even the numbers and the booleans, so the first time value comes back as a string in JavaScript, you will already know why. The optional slash on void elements does nothing; ignore it.

How HTML, CSS, and JavaScript split the work

A finished web page is usually built from three languages, and each has one job:

  • HTML is the structure: the headings, text, images, and buttons.
  • CSS is the style: the colours, fonts, spacing, and layout.
  • JavaScript is the behaviour: what happens when you click, type, or scroll.

A common way to picture it: HTML is the walls and rooms of a house, CSS is the paint and furniture, and JavaScript is the electricity that makes things switch on. You are learning the walls first, because there is nothing to paint or wire up until the structure exists.

The three languages form a layered stack, and the layering is intentional. HTML provides structure and meaning. CSS reads that structure and describes how it should look. JavaScript reads and changes the structure in response to events.

Keeping them separated is a discipline worth building early. When your content lives in HTML, your presentation in CSS, and your behaviour in JavaScript, you can change each one without disturbing the others. Mixing them, for example forcing layout with <br> tags or inline styles everywhere, works at first and becomes painful fast.

The separation of concerns across the three is not just tidiness, it is what makes pages resilient. A page whose meaning is fully carried by its HTML degrades gracefully: if CSS fails to load, the content is still readable and ordered; if JavaScript is disabled or errors, the core content is still there. This is the practical argument for progressive enhancement: build a working document in HTML first, then layer style and behaviour on top.

It is also an accessibility and performance argument. Assistive technology reads the DOM, so meaning that lives in HTML is available to it, while meaning faked with CSS or injected late by JavaScript often is not. And HTML is what the browser can parse and paint first; content that depends on a JavaScript round trip to appear is content the user waits for. When you are deciding where a piece of the page should live, the default answer is HTML, and you move up the stack only when structure alone cannot do the job.

JunoHow HTML, CSS, and JavaScript split the work Three languages, three jobs: HTML is structure, CSS is style, JavaScript is behaviour. You are starting with HTML because it is the part everything else sits on. Once these walls are up, the paint and the wiring have somewhere to go.
JunoHow HTML, CSS, and JavaScript split the work Structure in HTML, presentation in CSS, behaviour in JavaScript, kept apart on purpose. Change one without breaking the others, and resist the urge to fake layout in HTML. That habit is cheap to build now and expensive to unlearn later.
JunoHow HTML, CSS, and JavaScript split the work Put meaning in the HTML and the page degrades gracefully when CSS or JavaScript falls over, which is also what makes it accessible and fast. That is the whole case for progressive enhancement. When you are unsure where something belongs, start at the bottom of the stack and only climb when structure alone cannot carry it.

Your first look at a full page

Here is a complete, if tiny, web page. You will meet every part of it properly in the next chapters, so do not worry about the details yet. For now, notice that it is all made of the tags and attributes you have already seen:

Below is a minimal but complete HTML document. Every real page starts from roughly this shape: a doctype, an <html> root, a <head> for information about the page, and a <body> for the content the visitor sees.

A complete document has a required skeleton, and it is worth reading closely even though it looks like boilerplate. Each line has a job, and the next chapters explain why each one earns its place rather than treating it as a magic incantation to copy.

html
<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <title>My first page</title>
  </head>
  <body>
    <h1>Welcome</h1>
    <p>This is a paragraph of text on my first web page.</p>
  </body>
</html>

Read from the top: the first line tells the browser this is a modern HTML page, <html> wraps everything, <head> holds behind-the-scenes information like the page title, and <body> holds what you actually see. The heading and paragraph from earlier live inside the body, because they are content for the visitor.

The <head> holds metadata: things about the page that are not shown in the page body, like its title (which appears in the browser tab) and its character encoding. The <body> holds the visible content. This split, information about the page versus content of the page, is the first structural decision every document makes.

Note the ordering and why it matters: <meta charset> comes first in the head so the parser knows how to decode the bytes of the rest of the document before it reads them. The lang attribute on <html> informs screen readers and translation tools. None of this is decoration. The head configures how the document is parsed and understood, and the body is the content that configuration applies to. The next chapter, on your first HTML page, takes this skeleton apart line by line.

JunoYour first look at a full page Every page is built from a small, repeating skeleton: a doctype, then <html> wrapping a <head> and a <body>. The head is behind-the-scenes info, the body is what people see. You will take this apart properly next, so a quick look is all you need right now.
JunoYour first look at a full page The core split is metadata in the head, visible content in the body. Almost every document you write starts from this exact shape, so it is worth recognising on sight. The next chapter walks each line.
JunoYour first look at a full page The skeleton is ordered for a reason: charset before content so the parser can decode the rest, lang for assistive tech and translation. Treat none of it as filler. Structure and understand it now and the head stops feeling like a magic block you paste in.