Tech & AI, Explained

how-the-web-works

10 min read

How the web works

Status: 🟩 COMPLETE Last updated: 2026-06-20 Plain-English tagline: Type a URL, get a page. Here’s exactly what happens in the half-second between those two events.

In plain English

The web is a conversation between computers. Your browser is one participant. A web server somewhere else is the other. They agree on a language (HTTP) for asking and answering. Your browser asks “give me this page”; the server answers with HTML, CSS, JavaScript, images. Your browser assembles all of that into the picture on your screen.

That’s the whole web. Everything else is detail.

The web is built on top of the internet (the network underneath that lets any two computers find each other) — but the two are not the same thing. The internet also carries email, video calls, online games, file transfers. The web is one particular pattern of conversation that happens on the internet.

Why it matters

If you’re building webapps, “the web” is your medium. Like a writer needs to know what a page is and what a book is, a webapp developer needs to know what a request is, what a response is, and what happens between them. Most production bugs trace back to a wrong assumption about something covered in this entry.

The cast of characters

Three actors and one phone book:

CharacterWhat it does
Browser (client)The program on your device that requests pages and renders them. Chrome, Firefox, Safari, Edge.
ServerA computer somewhere that holds the website’s files and runs its code.
DNSThe phone book that maps human names (stmarkbible.com) to numeric addresses (IP addresses).
Network (the internet)The wires, radios, and routers that carry messages between any two computers.

The journey of a single page load

Let’s follow what happens when you type stmarkbible.com and press Enter.

Step 1: The browser parses the URL

A URL is a structured address:

https://www.stmarkbible.com/quiz?level=3
└────┘   └────────────────┘└────┘└──────┘
scheme    host              path  query string
  • Scheme: https — use HTTPS (encrypted HTTP). Other schemes exist (ftp, mailto) but for the web it’s http or https.
  • Host: the website’s name. The bit the browser will ask DNS about.
  • Path: the specific page or resource on the server.
  • Query string: optional extra parameters.

Step 2: DNS lookup — turning the name into a number

Computers don’t talk to “stmarkbible.com.” They talk to IP addresses — numeric addresses like 76.76.21.21. The browser asks the DNS system: “what’s the IP address for stmarkbible.com?”

DNS lookups go through several levels of cache (your computer’s, your router’s, your ISP’s, the root servers). It’s surprisingly fast — typically tens of milliseconds, often less because the answer is cached somewhere along the chain.

The answer comes back: “stmarkbible.com is at IP 76.76.21.21” (one of Vercel’s servers).

Step 3: Open a connection

The browser opens a network connection to that IP address. For HTTPS, this involves:

  1. TCP handshake — three messages back and forth confirming both sides are ready to talk. (Imagine: “Hello?” “Hi.” “Great, let’s chat.”)
  2. TLS handshake — exchanging cryptographic keys so the rest of the conversation is encrypted. The server proves its identity by presenting a certificate (signed by a trusted authority). This is what produces the padlock icon in the browser.

After the handshakes, both sides have a secure, encrypted, two-way channel. This whole process takes ~50–200 milliseconds depending on distance.

Step 4: The HTTP request

Now the browser sends its actual request. It looks like this (cleaned up):

GET /quiz?level=3 HTTP/2
Host: www.stmarkbible.com
User-Agent: Mozilla/5.0 (Windows; Chrome/126)
Accept: text/html
Accept-Language: en-AU
Cookie: session_token=abc123

The first line says “I want to GET the resource at /quiz?level=3 using HTTP version 2.” The lines below are headers — metadata about the request (what browser, what language preference, what cookies it’s carrying for this site).

The browser sends this whole thing over the encrypted connection. Done in microseconds.

Step 5: The server thinks

The server receives the request and figures out how to respond. For a static site, that might mean “look up this file on disk.” For a webapp, that might mean:

  1. Check the session cookie → who is this user?
  2. Run server-side code (e.g. a Next.js Server Component on Vercel)
  3. Query the database (e.g. Supabase) for the relevant data
  4. Render an HTML page with that data
  5. Send it back

This whole process — depending on the complexity — takes anywhere from 10ms (static page) to a few hundred milliseconds (database-backed, server-rendered page).

Step 6: The HTTP response

The server sends back a response that looks like this:

HTTP/2 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 12450
Cache-Control: max-age=300
Set-Cookie: session_token=abc123; Secure; HttpOnly
 
<!DOCTYPE html>
<html lang="en">
  <head><title>Quiz · St Mark's Bible Quest</title></head>
  <body>...</body>
</html>

The first line says “version, status code, status text.” 200 OK means success. Other common ones:

CodeMeaningReal-world meaning
200OKAll good
301Moved PermanentlyThis URL has a new home; remember the new one
302/307Found / Temporary RedirectGo look over there instead, just this time
304Not ModifiedYou already have this; use your cache
400Bad RequestYour request was malformed
401UnauthorizedYou’re not logged in
403ForbiddenYou’re logged in but not allowed
404Not FoundThis page doesn’t exist
500Internal Server ErrorThe server broke; not your fault
503Service UnavailableThe server’s overwhelmed or down

Then headers, then a blank line, then the body (the HTML).

Step 7: The browser renders

This is where it gets interesting. The browser doesn’t just slap the HTML on screen. It does several things in parallel:

  1. Parse the HTML into a tree (the DOM).
  2. Parse the CSS (linked from <link> tags) into rules.
  3. Run any blocking JavaScript in the order it appears.
  4. Apply CSS to the DOM to figure out how each element should look.
  5. Layout — calculate where every element actually goes on screen.
  6. Paint — draw the pixels.
  7. Continue downloading any images, fonts, lazy-loaded scripts, etc.
  8. Hydrate if this is a React/Next.js page — attach event handlers to the rendered HTML so it becomes interactive.

The “first contentful paint” — the moment something appears on screen — typically happens 200ms–1.5s after the click, depending on connection, server speed, page complexity. The “page fully interactive” can be much later, especially for JS-heavy apps.

Step 8: The follow-on requests

The initial HTML almost always references other resources — images, stylesheets, JavaScript files, fonts. The browser makes additional requests for each of them. These can be served from CDN edge nodes (close to the user, fast) rather than the origin server.

For each additional request, steps 4–7 repeat (skipping the TCP/TLS handshake because the connection is reused, and skipping DNS because the answer is cached).

Static vs dynamic vs server-rendered

Three flavours of “page” in the modern web:

FlavourWhat happensExamples
StaticThe HTML was pre-built and just gets served. Fast, cacheable, no server logic per request.Most blogs, marketing sites, docs
Server-rendered (SSR)The HTML is generated fresh for every request by code running on the server.Logged-in dashboards, personalized homepages
Static + client-side data fetching (SPA-style)A static shell loads; JavaScript then runs and fetches data, building the page in the browser.Many React apps
Hybrid (Next.js App Router)Different pages can be any of the above. Same project.A modern Next.js webapp

Next.js makes the choice per-page seamless. A blog post page might be static; the dashboard might be server-rendered; the search results might be client-side. Same codebase.

The web vs the internet

People conflate these constantly. They’re related but distinct:

  • The internet is the underlying network — a global mesh of cables and radios and routers that lets any two connected computers exchange messages.
  • The web is one particular kind of conversation pattern (HTTP / HTML / browsers) on top of the internet.

Other things that ride on the internet but aren’t the web:

  • Email (SMTP, IMAP)
  • Video calls (Zoom, WebRTC for the data channels, etc.)
  • Online games (mostly custom protocols)
  • File transfer (FTP, SFTP)
  • Software updates
  • The SSH connection you make when you log into a server

So: when somebody says “the web is broken,” they usually mean HTTP/HTML stuff. When somebody says “the internet is down,” they mean the underlying network connection. Different layers.

HTTPS — the padlock explained

Without HTTPS:

  • Anyone on the network path (your ISP, the WiFi operator, governments) can read every request and response in plain text.
  • Anyone can modify the responses on the fly (injecting ads, scripts, malware).
  • You have no way to prove the server you’re talking to is the real one.

With HTTPS:

  • The conversation is encrypted end-to-end. The network path sees gibberish.
  • The server presents a certificate signed by a trusted authority, proving it really is stmarkbible.com.
  • Browsers refuse plain HTTP for almost everything in 2026; the padlock is now the default expectation.

Modern hosting (Vercel, Netlify, Cloudflare) handles HTTPS certificates automatically — you don’t have to think about it. But understanding what’s happening helps when you debug “why does my custom domain say ‘not secure’?” (usually: certificate hasn’t been issued yet — wait 5 minutes).

A concrete example: what each step takes

Approximate timings for stmarkbible.com/quiz?level=3 from Sydney:

StepTime
DNS lookup5–20 ms
TCP + TLS handshake50–150 ms
HTTP request travels to server10–50 ms
Server-side processing + database query50–300 ms
HTTP response travels back10–50 ms
Browser parses + first paint50–300 ms
Page fully interactive200–1500 ms
Total perceived load time0.4 – 2.4 seconds

For a fast site on a good connection, the total feels instant. For a slow site, every step adds up.

Common gotchas

  • Confusing the URL bar with the actual request. The URL bar is what you type. The request is what the browser sends to the server. They’re related but the browser may rewrite, add headers, follow redirects, or fall back to another URL before the actual request goes out.

  • Caching makes things look weird. “Why isn’t my change showing?” Almost always: the browser cached the old version. Hard refresh (Ctrl+Shift+R) or DevTools “disable cache.” For real users, you control caching via response headers.

  • HTTPS errors are sometimes the easiest to fix in the world. “Not secure” → certificate hasn’t been issued or has expired. On Vercel, this is usually fixed by waiting 5 minutes for DNS to propagate. Don’t panic.

  • DNS changes propagate slowly. When you change a domain’s DNS records, the change can take minutes to days to be seen everywhere (because DNS resolvers cache answers). Don’t repeatedly change records hoping for an instant fix — wait, then verify.

  • Mixed content errors. An HTTPS page that loads an HTTP image: the browser blocks the image with a “mixed content” warning. All resources must be HTTPS on an HTTPS page.

  • Same-origin policy and CORS. A page from siteA.com can’t make most kinds of requests to siteB.com unless siteB.com explicitly allows it via CORS headers. This stops malicious sites from reading your bank balance — but also causes ~50% of “but it works in Postman!” confusion.

  • The browser does a lot you don’t see. Service workers caching things, preloading, prefetching, brotli decompression, image format negotiation. Most of the time this helps; occasionally it confuses debugging.

See also

Sources

Graph View

Backlinks