What happens when you load a web page

Most beginners skip this and end up debugging by guesswork later. Between typing a URL and seeing a page, your browser finds a server, asks it for files, and turns those files into pixels. You don't need to memorize every detail — you need the shape of it in your head, so that when something breaks you know which step to look at.

Step 1: Finding the server with DNS

Computers on the internet find each other by IP address (like 93.184.215.14), not by names like example.com. So before anything else, your browser has to translate the name into an address. That lookup is DNS, the internet's phone book.

The browser first checks what it already remembers (its own cache and your operating system's). If the answer isn't there, it asks a DNS resolver, usually run by your internet provider or a service like Cloudflare or Google, which finds the answer and passes it back.

If this step fails, nothing else can happen. That's why a typo in a domain gives an error like "server's DNS address could not be found" — no request was ever sent to any website.

Step 2: Opening a connection

With an IP address in hand, the browser opens a connection to the server. Traditionally that's a TCP connection: a short back-and-forth that sets up a reliable channel where data arrives complete and in order. (Newer HTTP/3 uses a different transport called QUIC, but the idea is the same.)

For an https:// address, the browser and server also perform a TLS handshake. The server proves its identity with a certificate, and both sides agree on encryption keys. From then on, anyone in between — say, on public café Wi-Fi — can see which server you're talking to, but not what you send or receive.

The padlock means the connection is encrypted and the certificate matches the domain. It does not mean the site itself is honest or safe.

Step 3: The HTTP request and response

Now the browser sends an HTTP request: a method (usually GET for loading a page), a path, and headers with extra information. The server sends back a response with a status code, headers, and a body.

GET /about HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Content-Type: text/html

Status codes tell you where to look when things go wrong:

• 2xx — success (200 OK)
• 3xx — go somewhere else (a redirect)
• 4xx — the request was the problem, e.g. 404 Not Found for a path that doesn't exist
• 5xx — the server failed while handling it, e.g. 500; the cause is in server code or logs

Any status code at all means the server was reached.

Step 4: Turning HTML, CSS, and JS into a page

The response body is HTML, and the browser parses it top to bottom into a tree of elements called the DOM. Whenever it meets a link to CSS, an image, or a script, it requests that file too.

CSS is combined with the DOM to work out what each element looks like and where it goes (layout), and then the result is painted to the screen.

JavaScript is the one to watch. A plain <script src="app.js"> makes the parser pause, download, and run the script before continuing. At that moment, elements further down the HTML don't exist yet, so code that looks for them finds nothing. Adding defer to the script tag (or putting the script at the end of the body) runs it after the HTML is parsed.

One page, many requests

A single page load is rarely one request. A typical site asks for the HTML, then several stylesheets, scripts, fonts, and images, plus data from APIs while the page is running. Each is its own request with its own status code, and any one of them can fail while the rest succeed. A page whose HTML loads but whose CSS file returns 404 shows up as plain, unstyled text.

Browsers also cache: they keep copies of files they've downloaded, and on a later visit they reuse them or ask the server "has this changed?" (a 304 Not Modified answer means "no, use your copy"). That's why second visits are usually faster — and why you sometimes need a hard refresh to see a change you just made.

Try it: watch a real page load

Open any site you use, then open your browser's developer tools (F12, or Cmd+Option+I on macOS) and choose the Network tab. Reload the page and look at what appears:

• The first row is usually the HTML document. Click it and find the status code and response headers.
• Scroll through the other rows. Which are CSS, JavaScript, images, fonts?
• Reload again and notice files served from cache.
• Type a path that doesn't exist on the same site and find the 404.

Then explain the whole journey out loud, from URL to pixels, in six sentences or fewer. If you can do that, you have the mental model.