What is HTML

Every website you've ever visited starts life 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 move, you have to say what's on it. That description is HTML.

A page is structured text

HTML stands for HyperText Markup Language. The word that matters is markup.

You take plain text and mark up which parts are headings, which are paragraphs, which are links. You're not giving the computer instructions to follow. You're labelling content so the browser knows what each piece is.

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

<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 structured text HTML is how you label the parts of a page so the browser knows what they are. You're not writing instructions, you're marking up content: this bit's a heading, this bit's a paragraph. That's the whole idea, and everything else builds on it.

If that feels too simple to be the real answer, it isn't. I spent my first week looking for the complicated part, and there wasn't one.

JunoA page is structured text The word for this is declarative: you describe the structure you want, and the browser works out how to produce it. No logic lives here, no loops, no variables.

That's why HTML isn't a programming language in the usual sense. It computes nothing, it structures content. Keep its job clear in your head and CSS and JavaScript get much easier to place, because when you catch yourself asking "how do I make HTML do X", that's usually the signal you've wandered into one of the other two.

JunoA page is structured text The browser parses your markup into a tree of objects called the DOM, the Document Object Model: the live, in-memory representation of the page. Your source text is the input, and the DOM is what actually gets rendered and what every other web technology talks to.

That framing explains a lot of HTML's behaviour. Parsing is deliberately forgiving, so a missing closing tag or a misnested element rarely throws an error. The parser follows a defined recovery algorithm and builds a valid tree anyway, which is what 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 well-formed structure is on you rather than the parser. It's the difference between a page that survives its second developer and one that doesn't.

Elements, tags, and attributes

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

<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, and the content is what your visitor actually reads.

You can also give a tag extra information with an attribute, written as a name="value" pair inside the opening tag. A link needs to know where it goes, so you tell it with href:

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

A few elements have no content at all, so they have no closing tag either. These are void elements, and you'll meet them constantly: <img>, <br>, <input>, <hr>. Everything they need lives in their attributes, so there's nothing to wrap and nothing to close.

<img src="golden-retriever.jpg" alt="A golden retriever sitting in tall grass">

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.

Please don't try to memorise every tag. There are over a hundred and nobody holds them all in their head. You'll pick up the handful you need, and look up the rest forever, same as the rest of us.

JunoElements, tags, and attributes Worth pinning the vocabulary down now, because people use it loosely. A tag is the text you type, <p> or </p>. An element is the whole thing the parser produces: the tags, their content, and any descendants. An attribute configures it.

The moment you're reading someone else's markup in review, "the tag" and "the element" stop being interchangeable. Void elements are the ones that catch people: no content, no closing tag, everything in the attributes.

JunoElements, tags, and attributes Tag, element, and attribute mean three different things, and keeping them straight pays off the first time you're reading a stack trace at speed.

Attribute values are strings at this layer, every last one, including the numbers and the booleans. disabled is a boolean attribute whose mere presence means true, and <input value="5"> holds the string "5" until something reads it as a number. So the first time your arithmetic turns into concatenation in JavaScript, you'll already know why.

The trailing slash you sometimes see on <br /> is optional and does nothing whatsoever, a holdover from XHTML. Ignore it, and don't let anyone tell you otherwise.

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.

Here's the picture I always come back to. HTML is the walls and rooms of a house, CSS is the paint and the furniture, and JavaScript is the electricity that makes things switch on.

You're learning the walls first, because there's nothing to paint or wire up until the structure exists.

Keeping the three separated is a habit worth building early. When your content lives in HTML, your presentation in CSS, and your behaviour in JavaScript, you can change any one of them without disturbing the other two.

JunoHow HTML, CSS, and JavaScript split the work Three languages, three jobs: HTML is structure, CSS is style, JavaScript is behaviour. You're starting with HTML because it's the part everything else sits on.

Once these walls are up, the paint and the wiring have somewhere to go. And you can build a real, useful page with nothing but this layer, which is a nice thing to know when the other two feel far away.

JunoHow HTML, CSS, and JavaScript split the work The layering is deliberate. HTML provides structure and meaning, CSS reads that structure and describes how it should look, JavaScript reads and changes it in response to events.

Resist the urge to fake layout in HTML: stacked <br> tags for spacing, an empty <div> to push something down. It works at first and gets painful quickly. Cheap to build the habit now, expensive to unlearn on a codebase that's already shipped.

JunoHow HTML, CSS, and JavaScript split the work The separation is more than tidiness, it's what makes pages resilient. A page whose meaning is fully carried by its HTML degrades gracefully: if CSS fails to load the content stays readable and ordered, and if JavaScript is disabled or throws, the core content is still sitting there. That's the whole case for progressive enhancement, and it's held up for twenty years while a lot of louder ideas haven't.

It's an accessibility and performance argument too. 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 isn't. HTML is also what the browser can parse and paint first, and content that waits on a JavaScript round trip is content your user waits for.

When you're unsure where something belongs, start at the bottom of the stack and climb only when structure alone can't carry it. The teams I've watched regret this decision all regretted it in the same direction.

Your first look at a full page

Here's a complete web page, tiny but real. You'll meet every part of it properly over the next few chapters, so don't worry about the details yet. For now, notice that it's all built from the tags and attributes you've already seen:

<!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 it 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're content for your visitor. That split, information about the page against content of the page, is the first structural decision every document makes.

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 the same small 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'll take this apart properly in the next chapter, so a quick look is all you need right now. It looks like a lot the first time and it stops looking like anything at all by about the fifth.

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's worth recognising on sight.

Your editor will scaffold it for you, and it's still worth being able to spot what's missing when the scaffold is wrong.

JunoYour first look at a full page The skeleton is ordered for a reason. <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, and lang on <html> tells screen readers and translation tooling which language they're dealing with.

None of it is filler. The head configures how the document gets parsed and understood, and the body is the content that configuration applies to. Understand it once and you'll start editing it with confidence, which matters, because the head is where a surprising share of production bugs quietly live.