What happens when you load a page

You type an address, press enter, and a page appears. It feels like one action. It is in fact a chain of separate systems — naming, routing, encryption, transfer, rendering — each solving a distinct problem, most of them invented decades ago and still doing their job. Following the sequence once makes a surprising amount of everyday computing legible, including the security warnings people are asked to interpret.

First the name has to become a number

Computers on a network do not find each other by name. They find each other by IP address, a numeric label that identifies a specific destination. Human-readable names exist because nobody wants to memorise numbers.

So the first step is a lookup. Your device asks the Domain Name System — a distributed directory spread across many servers worldwide — to translate the name into an address. If it has asked recently, the answer is cached locally and the step takes no time at all. If not, the query walks up a hierarchy: servers responsible for the top-level domain point to servers responsible for the specific domain, which return the address.

DNS is worth understanding because a striking share of everyday internet failures are DNS failures, and they present confusingly. The site is reachable, your connection works, but the name cannot be resolved, so nothing happens at all.

Then a connection has to be established

With an address in hand, your device opens a connection to that machine. The protocol doing the heavy lifting is TCP, and its central promise is reliability: data sent will arrive complete and in order, or the sender will know it failed.

That promise is not free. The underlying network makes no such guarantee — packets can be lost, duplicated or arrive out of sequence. TCP handles this with acknowledgements and retransmission, quietly reassembling a clean stream out of a messy one. It begins with a brief handshake, an exchange establishing that both ends are present and ready.

This is also where distance starts to matter. Every round trip costs time bounded by physics, and a server on another continent cannot answer faster than light allows. It is why content delivery networks exist: keep a copy of the data physically nearer the user and the round trips shorten.

Then it gets encrypted

If the address began with HTTPS, an additional negotiation happens before any content moves. The server presents a certificate — a document, signed by an authority your device already trusts, asserting that this server is genuinely the one for that name.

Your browser checks that signature. If it validates, the two sides agree on encryption keys and everything afterwards is scrambled in transit. If it does not validate, you get the warning page that people are so practised at clicking through.

It is worth being precise about what this does and does not guarantee. It confirms you are talking to the holder of that domain name and that nobody in between can read or alter the traffic. It says nothing whatever about whether the site is honest. A fraudulent site can hold a perfectly valid certificate, and most do. The padlock means the channel is private, not that the destination is trustworthy — a distinction that a great deal of security advice has historically muddled.

Then the actual request

Only now does the browser ask for anything. It sends an HTTP request naming the resource it wants, along with details about itself. The server replies with a status code and, usually, some content.

Those codes leak into everyday life. 200 means success. 301 and 302 mean the resource has moved. 404 means the server understood the request and has no such resource. 500 means the server encountered its own error — which is why a 500 tells you the problem is at the far end and a 404 tells you the address is wrong.

Then the page gets built

What comes back is not a picture. It is HTML, a text document describing structure: this is a heading, this is a paragraph, this is a link. The browser parses it and constructs an internal model of the document.

That document references other things — stylesheets describing appearance, scripts adding behaviour, images, fonts. Each of those is a separate request, and a modern page may trigger dozens. The browser fetches them in parallel where it can, applies the styling rules to the structure, runs the scripts, and paints the result.

This is why pages sometimes appear briefly unstyled, or jump as they finish loading. You are watching the stages arrive out of order: structure first, appearance a moment later, behaviour later still.

The whole thing is a stack of old ideas

What is striking is the age of the machinery. The internet's core routing protocols date from the 1970s. DNS arrived in the early 1980s. The web itself — HTTP, HTML, the URL — was proposed in 1989 and released without patent or licence fee, a decision that shaped everything after it.

They have been extended enormously but not replaced, because each layer was designed to know as little as possible about the others. TCP does not care what it carries. HTTP does not care how packets are routed. That separation is why the system absorbed video, encryption and mobile devices without being rebuilt.

It also explains why the internet and the web are not the same thing, though the words are used interchangeably. The internet is the network. The web is one service running on top of it, alongside email and many others. Getting that distinction straight is the difference between having a vague sense that it all works somehow, and being able to reason about which part just broke.