What Are HTML and CSS?

What HTML is

HTML (HyperText Markup Language) is the language in which web pages are written. It is a markup language, not a programming language: it has no variables, loops or calculations. Instead, you wrap pieces of text in tags that say what each piece is. "This is the main heading", "this is a paragraph", "this is a list with two items", "this word links to another page".

Here is a small piece of HTML for the outage page of Kestrel Energy, the fictional energy supplier used throughout this encyclopedia. Below the code you see the result, rendered live by your own browser:

<h1>Power outage in Riverside</h1>
<p>Our engineers are working on a fault in the <strong>Riverside</strong> area.</p>
<ul>
  <li>Reported: 08:40</li>
  <li>Expected fix: 12:00</li>
</ul>
<p><a href="#">Report another outage</a></p>

<h1> marks the main heading, <p> a paragraph, <strong> text of strong importance, <ul> an unordered list with <li> list items, and <a> a link. Even without any styling, the browser already shows a large bold heading, bullets and an underlined blue link. Those are the browser's default styles: a built-in stylesheet that gives every element a reasonable look.

The "hypertext" in the name is the link: text that leads to other text. Links between documents are what turned a collection of files into the World Wide Web. The next page, HTML Document Structure, shows the parts of a complete HTML file.

What CSS is

CSS (Cascading Style Sheets) is the language that says how HTML elements are displayed. A stylesheet is a list of rules; each rule picks some elements with a selector and gives them declarations, pairs of a property and a value. Here is the same HTML with a few rules added:

<h1>Power outage in Riverside</h1>
<p>Our engineers are working on a fault in the <strong>Riverside</strong> area.</p>
<ul>
  <li>Reported: 08:40</li>
  <li>Expected fix: 12:00</li>
</ul>
<p><a href="#">Report another outage</a></p>

body {
  font-family: system-ui, sans-serif;
  max-width: 32rem;
}
h1 {
  font-size: 1.4rem;
  border-bottom: 3px solid darkorange;
  padding-bottom: 0.25rem;
}
strong { color: darkred; }
ul { list-style: none; padding: 0; }
li { padding: 0.2rem 0; }
a { color: darkblue; }

Not a single tag changed, yet the page looks different: another font, a smaller heading with an orange line, no bullets. The rule h1 { font-size: 1.4rem; } reads as "for every h1 element, set the font size to 1.4 times the root font size". How selectors work, and what happens when two rules disagree, is the subject of CSS Basics: Selectors, the Cascade and Specificity.

"Cascading" refers to exactly that conflict resolution: styles can come from the browser's defaults, from the site's stylesheets and from the user (for example a larger default font size), and the cascade is the set of rules that decides which value wins.

Structure versus presentation

The two examples above show the core idea of this topic: HTML carries the structure and meaning, CSS carries the presentation. This division of work is often called separation of concerns, and it pays off in practice:

• One change, every page. A site with a thousand pages can share one stylesheet. Changing the brand color means changing one line, not a thousand files.
• Content that works without the looks. A screen reader announces "heading level 1" for an h1, whatever its font size. Search engines, reader modes, translation tools and printers all use the structure, not the colors.
• Different devices, same HTML. CSS can lay the same content out in one column on a phone and three columns on a wide screen (see Responsive Design).

JavaScript is the third language of the web. It adds behavior: reacting to clicks, checking input, loading new data without reloading the page. A good rule of thumb: HTML for what it is, CSS for how it looks, JavaScript for what it does. The JavaScript topic covers the third part; this topic stays with the first two.

Three ways to add CSS

CSS can reach an HTML page in three ways:

1. External stylesheet: a separate .css file, linked from the page's head with <link rel="stylesheet" href="…">. This is the normal choice for real sites: one file, cached by the browser, shared by all pages.
2. Internal stylesheet: rules inside a <style> element in the page's head. Useful for a single page, a demo or an email template.
3. Inline style: declarations in the style attribute of one element. Handy for a quick test; hard to maintain, because the style is scattered through the HTML.

The example below is a complete document that uses an internal stylesheet and one inline style:

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>Portal status</title>
    <style>
      p { font-family: system-ui, sans-serif; }
      .ok { color: darkgreen; }
    </style>
  </head>
  <body>
    <p class="ok">All systems are running.</p>
    <p style="color: darkred;">Planned maintenance tonight from 22:00.</p>
  </body>
</html>

For an external stylesheet, the page links to the file and the file contains only CSS:

<link rel="stylesheet" href="css/portal.css">

/* css/portal.css */
p { font-family: system-ui, sans-serif; }
.ok { color: darkgreen; }

The href is a URL like any other: relative to the page, as explained in Links, Images and Media. If the path is wrong, the page still loads, just without styles. That bare, black-on-white page is a classic support ticket, and the first thing to check is a 404 for the CSS file in the Network panel of the browser developer tools.

A short history

Tim Berners-Lee created HTML at CERN around 1990–1991, together with HTTP and the first browser. The first HTML had only a small set of tags: headings, paragraphs, lists, links. Browsers soon added their own tags (and their own ideas about presentation, such as the <font> tag), which made pages look different in each browser.

Since 2018 the W3C has marked HTML 4.01 and XHTML 1.0 as superseded, and the old HTML5 address on w3.org now redirects to the WHATWG standard. "HTML5" survives as a popular name for modern HTML, especially the elements it introduced, such as <video>, <nav> and <article>, but it is no longer a version you can target.

The standards today

A web standard is an openly published specification that describes exactly how a web technology must behave, so that independently built browsers produce the same result. Standards are why a page written once works in Chrome, Firefox and Safari alike.

HTML: the WHATWG Living Standard

The WHATWG (Web Hypertext Application Technology Working Group) is the standards body, founded in 2004 by browser makers, that maintains HTML and several related standards such as DOM, URL and Fetch. Its HTML Living Standard is the single specification of HTML. It has no version numbers: it is updated whenever a change is agreed (when this page was written it showed "Last Updated 1 October 2026"), and the browser makers work on it together in public.

This has a practical consequence: you never write "HTML5" or "HTML Living Standard" code. You write HTML, starting with the short doctype <!doctype html>, and you check per feature whether browsers support it.

CSS: modules, not versions

CSS is still developed at the W3C, by the CSS Working Group. After CSS 2.1 the language was split into modules, each with its own level: Selectors Level 4, Color Level 4, Cascade Level 5, and so on. There never was one "CSS3" document; the name was used for the first wave of modules. Every year or so the group publishes a snapshot of what counts as CSS; the CSS Snapshot 2026 says it plainly: "There is no CSS Level 4."

Checking browser support

Because both languages keep growing, the useful question is never "which version?" but "does this feature work in the browsers my visitors use?". MDN's reference pages and caniuse.com show a Baseline badge per feature: newly available once it works in the current versions of Chrome, Edge, Firefox and Safari, and widely available 30 months later. The page Custom Properties and Modern CSS explains Baseline in detail; this topic gives the status of newer features "as of 2026", because it changes every few months.

How a browser turns code into a page

When the HTML of a page arrives, the browser's rendering engine (Blink, Gecko or WebKit) goes through a fixed series of steps:

1. Parse the HTML into a tree of objects, the Document Object Model (DOM). Every element and piece of text becomes a node.
2. Parse the CSS (the browser defaults plus every stylesheet) into a similar structure, often called the CSSOM.
3. Match and compute styles: for every visible node, find the rules that apply, settle conflicts with the cascade and compute final values. Elements with display: none and the contents of <head> drop out here; the result is the render tree.
4. Layout: work out the size and position of every box, based on the width of the window.
5. Paint: draw text, colors, borders and images into pixels on the screen.

Two consequences are worth remembering. First, a browser does not show the page until the stylesheets in the head have loaded (otherwise you would first see the unstyled page flash by), so a slow CSS file delays the whole page. Second, resizing the window or rotating a phone triggers layout again; that is how one page adapts to many screen sizes.

The full journey, from typing a URL to this rendering step, is described in How the Web Works.

Browsers forgive broken HTML

A Python program with a missing bracket refuses to run. HTML is different: the specification defines how to parse documents "whether they are syntactically correct or not". Every browser repairs broken markup in exactly the same, standardized way, and shows the page anyway. Take this paragraph, in which the bold and italic tags overlap:

<p>Meter <b>reading <i>saved</b> today</i></p>

The page displays without an error. Behind the scenes the parser closes the <i> where the <b> ends and opens a new <i> for "today", so the DOM no longer matches what you wrote. With a small typo that is harmless; with a forgotten </div> half the page can end up inside the wrong box, and the CSS that targets it stops applying.

This is why "it looks fine" is not proof that HTML is correct. An HTML validator, such as the W3C's Nu Html Checker at validator.w3.org/nu, lists these problems; the page Debugging HTML and CSS with Developer Tools shows how to find them in the browser. CSS is forgiving in a different way: a declaration the browser does not understand is simply skipped, and the rest of the rule still applies. That lets you write new CSS features without breaking older browsers.

What you need to start

Nothing beyond what is on any computer. HTML and CSS are plain text files: write them in a code editor (Visual Studio Code is a common, free choice; any editor that saves plain text works), save the file as index.html, and open it in a browser by double-clicking it. For a page with several files, keep the stylesheet in the same folder or a subfolder and link it with a relative path.

Two habits help from day one. Save files as UTF-8 (every modern editor does by default), and keep the developer tools open (F12, or Ctrl+Shift+I; on a Mac Cmd+Option+I) to see the DOM and the styles that really apply. When the page is ready to go online, Building and Publishing a Page takes it from a folder to a URL.