How the Web Works

What actually happens, step by step, between typing a web address and seeing a page appear on screen.

What is it?

Type an address into a browser and press enter, and a page shows up a moment later. That moment feels instant, but it's actually a whole chain of hand-offs happening across machines you'll never see.

First, your browser needs to figure out which computer on the internet is responsible for that address — the address you typed is a human-friendly name, not a location a computer can dial directly. So there's a lookup step that turns the name into a numeric address for a specific machine somewhere in the world.

Once your browser knows which machine to talk to, it sends that machine a request — basically a structured message saying "please send me the page at this address." That machine (a server) is a computer that sits listening for exactly these kinds of requests, all day, from anyone who asks.

The server figures out what to send back — it might be a file sitting on disk, or it might build the response fresh by pulling data from a database — and sends a response back across the same connection. That response usually contains a document, written in a language browsers understand, describing the content and structure of the page.

Finally, your browser takes that document and turns it into the visual page you actually see: it reads through the document, fetches any extra files it references (images, styling, additional code), and paints everything onto the screen in the right positions with the right colors and fonts.

All of this — the lookup, the request, the response, the rendering — is what people mean when they say "the web works." Later topics give names to each of these pieces individually.

Explain like I'm 10

It's like mailing a letter to a company using only their name — a directory first looks up their street address, the letter travels there, an employee reads it and writes a reply, and that reply travels all the way back to your mailbox.

Examples

The trip a request takes

1. You type: example.com
2. Browser looks up which server "example.com" points to
3. Browser sends: "GET / please"
4. Server sends back: an HTML document
5. Browser reads the document and displays it

This is the whole round trip in plain steps — no protocol names needed yet, just the shape of the conversation.

A page is rarely just one file

index.html          <- the page structure
  ├── styles.css     <- fetched separately, for appearance
  ├── logo.png       <- fetched separately, an image
  └── app.js         <- fetched separately, for behavior

The first document the browser gets almost always references more files. The browser reads it, notices those references, and goes and fetches each one — often several requests, not just one.

How it works

Under the hood, this whole process rests on a few cooperating systems: a naming system that maps human-readable addresses to machine locations, a network that can carry messages between any two connected computers, and an agreed-upon format both browser and server understand for asking for and describing a page.

None of these steps require you to think about wires or cables directly — your operating system and browser handle the actual networking. What matters at this level is the sequence: look up, request, respond, render.

[ You ]  --type address-->  [ Browser ]
                                 |
                          1. look up server
                                 |
                                 v
                          [ Naming lookup ]
                                 |
                          2. send request
                                 v
                            [  Server  ]
                                 |
                          3. send response
                                 v
                          [ Browser renders ]
                                 |
                                 v
                          [   Page shown   ]

Why does it exist?

This layered process exists because the web was designed to connect any browser to any server, run by different people, on different machines, anywhere in the world. Breaking the problem into separate steps — naming, requesting, responding, rendering — meant each piece could be built, understood, and improved independently, and it's the reason typing an address into any browser reliably works no matter who built that browser or who runs that server.

When to use it

Understanding this flow matters any time something on a website is slow or broken and you need to reason about where the problem is — is the lookup failing, is the server not responding, or is the page failing to render once it arrives? Every deeper web topic (HTTP, DNS, rendering, caching) is really just a closer look at one step of this same journey.

When not to use it

You don't need to think about this whole chain for everyday tasks like writing HTML or styling a button — those live entirely inside the "render" step. This mental model is most useful when something crosses the boundary between browser and server, or when things go wrong.

Common mistakes

  • Thinking the address you type is the server's actual location, rather than a name that gets looked up.

  • Assuming a webpage is a single file, when it's usually a document plus many separately fetched files.

  • Believing the page 'just appears' rather than being built by the browser step by step after the response arrives.

Practice exercises

  1. Easy:

    In your own words, list the four major steps that happen between typing an address and seeing a page.

  2. Medium:

    Open your browser's developer tools, go to the Network panel, and reload a page. Count how many separate files were fetched to build that one page.

  3. Hard:

    Explain what might go wrong at each of the four steps (lookup, request, response, render) and how the symptom would look different to a user in each case.

Interview questions

At a high level, what happens between typing a URL and seeing a page?

The browser looks up which server the address belongs to (DNS), opens a connection and sends that server a request, receives a response containing the page's content, and then renders that content on screen.

Is a webpage usually a single file?

No. The initial HTML document typically references additional files — stylesheets, images, scripts — that the browser discovers while parsing it and fetches separately, often as many concurrent requests.

Why does the web need a naming lookup step at all?

Because humans use readable names like example.com, but computers need a numeric address (an IP address) to actually open a connection; DNS is the lookup step that translates one into the other.

What is DNS, and what does it actually return?

DNS (Domain Name System) is the naming lookup system for the web. Given a domain name, it returns the IP address of a server responsible for that domain, which the browser then connects to.

Why is looking up the same domain often faster the second time?

Browsers, operating systems, and network resolvers cache DNS answers for a period of time (its TTL), so a repeat lookup for the same domain can be served from cache instead of doing a full lookup again.

What's the difference between a domain name and an IP address?

A domain name is a human-readable label like example.com. An IP address is the actual numeric address of a machine on the network that a browser connects to; DNS is what maps one to the other.

What role does a port number play in a request, and what are the default ports for HTTP and HTTPS?

A port identifies which specific service on a server should handle the connection, since one machine can run many services. HTTP defaults to port 80 and HTTPS defaults to port 443, so those don't need to be typed explicitly in a URL.

What's the difference between HTTP and HTTPS?

HTTPS is HTTP layered on top of an encrypted connection (TLS). The request/response content is the same, but HTTPS prevents anyone intercepting the traffic from reading or tampering with it in transit.

What does it mean for HTTP to be a request/response protocol?

The browser (client) always initiates by sending a request, and the server always replies with a response; the server never pushes a page to a browser that didn't ask for it first.

What do the main HTTP status code categories mean?

2xx means success, 3xx means redirection to another location, 4xx means the client's request was somehow invalid or unauthorized (like 404 Not Found), and 5xx means the server failed while handling an otherwise valid request.

What happens when a server responds with a redirect?

The server sends back a 3xx status code and a Location header pointing to a different URL, and the browser automatically makes a new request to that URL instead of rendering the redirect response itself.

Why might a website use a CDN, and how does that change which server you actually talk to?

A CDN (content delivery network) serves cached copies of a site's files from servers geographically closer to the visitor. DNS for that domain resolves to a nearby CDN server rather than the site's single origin server, reducing latency.

What's the difference between latency and bandwidth?

Latency is how long it takes for a single piece of data to make the round trip; bandwidth is how much data can be transferred per second once the connection is flowing. A high-bandwidth connection can still feel slow if latency is high.

Why can a page technically finish loading but still show a blank screen for a while?

Getting a response is only one step; the browser still has to parse the HTML, fetch referenced files, compute layout, and paint pixels before anything is visible — a slow render step can delay the visible page well after the network work is done.

What's the difference between a client and a server in this model?

The client (typically a browser) initiates requests and renders what it gets back. The server listens for requests and decides what to send in response. The same machine could act as either role in different contexts.

How would the symptoms differ between a DNS failure, a server being down, and a rendering failure?

A DNS failure shows an error before any connection is attempted, often 'server not found.' A server being down shows a connection error after a lookup succeeds. A rendering failure can show a blank or broken page even though the network request completed normally.

Why is the very first request to a site often slower than later ones?

The first request has to pay the cost of DNS lookup, opening a TCP connection, and (for HTTPS) a TLS handshake, none of which are needed again if the browser reuses that same connection for subsequent requests.