What is HTML? How the Web Actually Works

Two Machines, One Conversation: The Client and the Server

Every website you have ever visited is, underneath everything else, a conversation between two computers. One of them is your computer — specifically, the browser running on it (Chrome, Safari, Firefox, Edge) — and it is called the client. The other is a computer somewhere else, usually in a data center, that stores the files a website is made of and answers requests for them. That machine is called the server. HTML is the language the server sends back, and the browser is the program that turns it into the page you actually see.

This client/server split is the single most important mental model for understanding the web, and it is worth being precise about who does what, because almost every bug and every performance question in front-end work eventually traces back to "which side of this line did that happen on."

THE CLIENT (your browser)               THE SERVER (a computer somewhere else)
─────────────────────────               ──────────────────────────────────────
- Sends requests for pages/files         - Stores the website's files (HTML,
- Parses HTML into the DOM                 CSS, JS, images) or generates them
- Parses CSS and applies styles            on the fly
- Runs JavaScript                        - Listens for incoming requests
- Paints pixels to your screen           - Decides what to send back, and sends it
- Handles clicks, scrolls, typing        - Has no idea what your screen looks like

A server does not know or care what browser you are using, how big your screen is, or what the page looks like once it arrives. Its job ends the moment it sends the response. Everything about how that response gets turned into a visible, interactive page — the entire subject of this HTML/CSS track — happens on the client. This is why the same HTML file can look completely different in Chrome on a laptop and Safari on a phone: the server sent identical bytes to both, and each browser did its own independent job of interpreting them.

DNS — Turning a Name You Type Into an Address a Computer Can Use

When you type chaduvuko.com into a browser, your computer does not actually know where that is. Computers on the internet find each other using numeric addresses called IP addresses (something like 142.250.80.14), not human-readable names. The system that translates a domain name into an IP address is called DNS — the Domain Name System — and it runs before a single byte of your actual request goes anywhere near the website itself.

1. You type "chaduvuko.com" and press Enter
2. Your browser checks its own cache — has it looked this up recently?
3. If not, it asks your OS, which asks a DNS resolver (often run by your ISP)
4. That resolver asks a chain of DNS servers: "who handles .com? who handles
   chaduvuko.com specifically?" — narrowing down step by step
5. Eventually a DNS server responds with an IP address, e.g. 76.76.21.21
6. Your browser now knows WHERE to send the actual page request

This lookup typically takes somewhere between a few and a few hundred milliseconds, and it is entirely invisible in normal browsing — you never see it happen, but every single request for a new domain triggers it at least once. Browsers and operating systems cache DNS results for a while specifically to avoid repeating this lookup on every single request.

HTTP — The Actual Conversation Between Browser and Server

Once the browser has an IP address, it opens a connection to that server and sends a request, written in a format called HTTP (HyperText Transfer Protocol — the "HT" in HTML's own name is not a coincidence, they were designed together). The server reads the request, decides what to do about it, and sends back a response. This request/response pair is the fundamental unit of everything that happens on the web — loading a page, submitting a form, an app fetching data — it is always, underneath, one of these cycles.

GET /index.html HTTP/1.1
Host: chaduvuko.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15)
Accept: text/html,application/xhtml+xml

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 4531

<!DOCTYPE html>
<html lang="en">
  <head><title>Chaduvuko</title></head>
  <body><h1>Welcome</h1></body>
</html>

Notice the 200 OK at the top of the response — that is an HTTP status code, a three-digit number telling the browser how the request went. 200 means success. You have almost certainly seen 404 (Not Found) when a page does not exist, and possibly 500 (Internal Server Error) when something broke on the server's end. These codes are grouped by their first digit, and recognising the groups is genuinely useful day to day.

1xx — Informational   (rare in day-to-day work; "request received, continuing")
2xx — Success          200 OK, 201 Created, 204 No Content
3xx — Redirection       301 Moved Permanently, 302 Found, 304 Not Modified
4xx — Client error      400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found
5xx — Server error      500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable

A single page load is rarely just one request/response cycle. The very first response usually contains the HTML — and that HTML then references other files (a stylesheet, a script, images, fonts) that the browser discovers by reading the HTML and requests separately, each with its own request/response cycle. A page with ten images and two stylesheets triggers at least thirteen separate HTTP round trips before it is fully loaded, all kicked off by parsing that first HTML response.

What "Rendering a Page" Actually Means, Step by Step

"Rendering" is the umbrella term for everything the browser does between receiving raw HTML bytes and showing you actual pixels on screen. It is not one step — it is a pipeline of several distinct stages, and understanding them individually is what makes performance concepts later in this track (and the CSS track after it) make real sense instead of feeling like folklore.

1. PARSE HTML  → builds the DOM (Document Object Model) — a tree of nodes
2. PARSE CSS   → builds the CSSOM (CSS Object Model) — a tree of computed styles
3. RENDER TREE → the DOM and CSSOM are combined: only the nodes that will
                 actually be visible (nothing hidden by "display: none") are kept
4. LAYOUT      → the browser computes the exact size and position of every
                 node in the render tree — "this box is 400px wide, starting
                 at (0, 120)"
5. PAINT       → pixels are actually drawn to the screen, in layers
6. COMPOSITE   → the layers are combined into the final image you see

The critical detail for right now: step 1 and step 2 happen in parallel as the browser streams the response, but step 3 (the render tree) cannot start until both the DOM and the CSSOM exist — meaning CSS is a genuine blocker to rendering anything at all. A page with HTML but no CSS parsed yet does not render partially styled content; the browser holds off on painting until it has both trees to combine. This single fact is the entire reason "render blocking" is a real, measurable performance concern and not just a phrase in a performance audit tool.

The DOM — A Live Tree, Not a Frozen Copy of Your HTML

The DOM (Document Object Model) is what the browser builds by reading your HTML file from top to bottom. Every tag becomes a node in a tree structure, with parent/child relationships that mirror how the tags were nested in the source. This is worth stating precisely, because it is the single most misunderstood idea for people new to web development: the DOM is not a copy of the HTML file — it is a live, in-memory object structure that starts out matching the HTML, but can be changed afterward by JavaScript, completely independently of whatever the original HTML file said.

<body>
  <h1>Hello</h1>
  <ul>
    <li>One</li>
    <li>Two</li>
  </ul>
</body>

body
 ├── h1  →  "Hello"
 └── ul
      ├── li  →  "One"
      └── li  →  "Two"

Each tag is a NODE. Nesting in the HTML becomes parent/child relationships
in the tree. Text inside a tag becomes its own text node, a child of the tag.

Once this tree exists in memory, JavaScript can add nodes, remove nodes, or change their attributes and text — and every one of those changes updates the live DOM immediately, without ever touching the original HTML file that was downloaded. If a script adds a new <li> after the page loads, that new node exists in the DOM and is visible on screen, but it was never part of the HTML the server actually sent. This distinction — the HTML file as a one-time starting point versus the DOM as an ongoing, mutable structure — is the entire foundation that JavaScript-driven interactivity is built on, and it is exactly what Part 06 shows you how to observe directly.

view-source vs DevTools Elements — Two Different Things That Look Similar

Every browser gives you two different ways to look "under the hood" of a page, and it is genuinely important to understand that they are not showing you the same thing.

view-source:https://example.com          →  the RAW HTML the server sent,
                                              byte for byte. Never changes,
                                              no matter what JavaScript does
                                              afterward. Read-only.

DevTools → Elements panel                  →  the LIVE DOM, right now, in its
                                              current state — including every
                                              change JavaScript has made since
                                              the page loaded. Editable, and
                                              constantly re-rendered as you
                                              watch it.

This is not a small technicality. Modern sites frequently modify the DOM heavily after the initial HTML arrives — fetching data and inserting it, removing loading placeholders, reacting to your clicks. If you view-source on a page built this way, you will often see a nearly empty <body>, because most of what you see on screen was added by JavaScript after the original HTML loaded. Open DevTools and inspect the Elements panel on the same page, and you will see the full, current structure — everything that is actually on screen right now.

HTML vs CSS vs JavaScript — Three Languages, Three Jobs

Before going further into HTML specifically, it is worth being precise about what HTML is for, since that scope defines the boundary of this entire track's first phase and shapes every decision about which tag to reach for later on.

HTML   →  STRUCTURE and MEANING.  What is this content? A heading? A list?
          A form? A navigation menu? HTML answers "what is this," not "what
          does it look like" or "what does it do."

CSS    →  PRESENTATION.  How should this content look? Colors, spacing,
          layout, fonts, animation. CSS answers "how does this appear,"
          and is the entire subject of Phases 3-5 of this track.

JAVASCRIPT →  BEHAVIOR.  What happens when the user interacts with this?
          Click handlers, form validation logic, fetching new data. Not
          covered in this track, but everything you learn about the DOM
          here is exactly what JavaScript manipulates.

This separation is a deliberate design decision, not an accident of history, and it is one of the most consequential ideas in front-end engineering: a well-built page should still make sense — its structure and meaning should still be intact — even with every line of CSS and JavaScript removed. A page that only "looks right" because of clever CSS tricks, with meaningless <div> tags standing in for headings, buttons, and lists, has broken this separation. You will see exactly why that matters concretely in the Semantic HTML module later in this phase, and it comes up constantly in real code review.

Debugging a "Missing Content" Ticket at a Seattle Retail Startup

<div id="product-description"></div>
<script src="/js/load-description.js"></script>
<!-- The real text only appears after this script runs in a real browser -->

<div id="product-description">
  <p>Waterproof, breathable 3-layer shell built for Pacific
  Northwest weather. Adjustable hood, pit zips, 20,000mm rating.</p>
</div>

Four Misconceptions About How the Web Works

5 Interview Questions — With Complete Answers

Mistakes Beginners Make Around How Pages Actually Load

Errors and Symptoms You Will Hit — And Exactly Why