How the Web Works

Updated 26 September 2026 · 6 min read

When you type a web address and press Enter, you start a short conversation between your device and a computer somewhere else. No magic tab appears from the cloud as a single blob. Several systems cooperate: the browser, DNS, a server, HTTP, then HTML, CSS, and JavaScript. This lesson walks through that path in order so the jargon has a place to sit. You do not need to become a network engineer. You do need a mental movie of what happens after Enter.

The browser is a client

A browser is a program that requests documents and then shows them. It is the client. The computer that answers is the server. Many servers can hide behind one name. Your browser does not usually speak to “the internet” as a whole. It speaks to one host at a time for each file it needs: the HTML page, then a stylesheet, then a script, then an image.

The address bar holds a URL (Uniform Resource Locator). A typical one:

https://www.example.com/menu/lunch?lang=en

Pieces: https is the scheme (how to talk, here HTTP over TLS). www.example.com is the host. /menu/lunch is the path. lang=en is a query string. The browser also sends extra data in headers (what formats it accepts, cookies it already has for that site, and so on). You do not type those; the browser attaches them.

If you are choosing languages to build this stack, JavaScript lives in the browser; other languages often live on the server. See choosing your first programming language.

DNS: names become addresses

Computers route packets to numeric addresses. People use names. DNS (Domain Name System) translates www.example.com into an IP address. Your device asks a resolver (often your ISP or a public resolver). The resolver looks up the name, perhaps using cached answers, and returns an IP.

If DNS fails, you get a “cannot find the server” style error before HTTP starts. If DNS points at the wrong machine, you might see a different site, a parking page, or a certificate warning. The web conversation never starts correctly if the name points at the wrong door.

You do not configure DNS to write your first HTML file on your laptop. You will meet it the first time you put a site on a real domain.

The HTTP request

Once the browser has an IP, it opens a connection. For https, it also completes a TLS handshake so the traffic is encrypted and the certificate matches the name. Then it sends an HTTP request. In simplified form:

GET /menu/lunch?lang=en HTTP/1.1
Host: www.example.com
Accept: text/html

GET means “give me this resource.” Other methods exist; POST is common for form submissions that change something. The path and query are the resource. Headers are extra facts. There may be a body (for POST). This is still just structured text (or a binary framing of it in newer HTTP versions). The idea is the same: a method, a target, headers, optional body.

Your first programs on your own machine skip all of this. They read the keyboard instead. The pattern is still input in, output out, as in what programming really is.

The HTTP response

The server software (and perhaps an application behind it) decides what to send back: an response with a status code, headers, and a body.

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

<!DOCTYPE html>
<html lang="en">
  <head><title>Lunch menu</title></head>
  <body><h1>Lunch</h1></body>
</html>

Status codes worth recognizing early: 200 success, 301/302 go elsewhere, 404 not found, 500 the server tripped on itself. The body for a page is often HTML. It might be JSON for an API, or a file download. Content-Type tells the browser how to interpret the bytes.

Static sites return files from disk. Dynamic sites run code to build the body (a template plus a database). As a user, you cannot always tell. As a beginner builder, start with static files. They are easier to reason about.

HTML, CSS, and JavaScript

Three languages share the tab:

HTML describes structure: headings, paragraphs, links, forms. It is not a programming language. It is a document.
CSS describes presentation: layout, colors, fonts. Also not a programming language in the everyday sense, though it is detailed.
JavaScript is a programming language the browser runs. It can change the document, listen to clicks, and request more data without a full page load.

The first response is usually HTML. In it, the browser finds <link> and <script> and <img> tags, then makes more HTTP requests for those URLs. That is why the Network panel in developer tools fills with many rows for one “page.” Each row is its own request/response.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>Lunch</title>
  <link rel="stylesheet" href="/styles.css">
</head>
<body>
  <h1>Lunch</h1>
  <button id="go">Show hours</button>
  <script src="/menu.js"></script>
</body>
</html>

If CSS fails to load, the structure still shows, unstyled. If JavaScript fails, the HTML should still be readable if you designed it that way. That is a kindness to users and to your future debugging.

What happens when you press Enter

The browser parses the URL (scheme, host, path, query).
It looks up the host in DNS (unless it already cached the IP).
It connects, using TLS if the scheme is https.
It sends GET (or another method) for the path.
The server returns a status, headers, and a body.
If the body is HTML, the browser starts building a document tree (the DOM).
It requests linked CSS, JS, and images the same way, in parallel when it can.
CSS is applied. JavaScript runs (depending on where you placed it and defer/async).
You see pixels. Further clicks may send more requests or run more JS.

Typing a search into the empty address bar may first go to a search engine, which is a different site. That is still the same movie, just not the host you thought you typed. Bookmarks skip typing; they still send HTTP.

When something “doesn’t load,” ask which step failed: DNS, TLS, HTTP status, a file 404, or a script error. That question is more useful than “the internet is down.” Script errors will look familiar after reading error messages, even though the traceback is in the browser console instead of a terminal.

A tiny local picture

You can open an HTML file from disk with a file:// URL. That skips DNS and most of HTTP. It is valid for learning tags. Some browser features (certain modules, cameras, precise cookies) expect a real http(s) origin. When you outgrow file URLs, a small local server appears in many language tutorials. Same HTML; now it arrives through HTTP on your machine talking to itself.

That is a good moment to remember: “full stack” just means both sides of this conversation. You do not need both on week one.

Checklist

Browser = client; it requests. Server = answers with status + body.
DNS turns names into IPs before HTTP runs.
HTTP is a request/response with methods, headers, and codes like 200 and 404.
HTML structures, CSS presents, JavaScript programs in the page.
One “page load” is often many HTTP requests.
When it breaks, name the step: DNS, TLS, status, file, or script.

Open your browser’s Network panel, reload a simple site, and click one row. Read the request URL and the status code. That single habit turns this lesson from a story into something you can see.

Related lessons

Beginner-level guidance; tools and versions change, so check official documentation for details.