What Happens When You Type a URL and Press Enter?

It's the most famous question in all of computing interviews, and for good reason: "What happens when you type a URL into your browser and press Enter?" You can answer it in three words ("the page loads") or you can answer it across an entire guide — because a complete answer touches nearly every system that makes the internet work.

This chapter is that answer at a glance: the whole relay race, start to finish, in plain English. Every step here becomes a full chapter later, so think of this as the map. We'll follow one request — you typing https://example.com and pressing Enter — from your keyboard to a server and back.

The journey in one picture

Six hand-offs. Each one is a distinct system, run by different organisations, using different protocols — and yet the whole thing completes in a fraction of a second. Let's walk each step.

Step 1: Your browser figures out what you meant

Before anything hits the network, your browser parses the URL. https://example.com/page breaks into:

• Scheme (https) — which protocol to speak, and that it should be encrypted.
• Host (example.com) — which machine to reach.
• Path (/page) — which resource on that machine.

The browser also checks its own caches first: is this page already stored locally? Do I already know this site's address? A surprising amount of "loading" is avoided entirely by cached answers — a theme that recurs at every layer of the internet.

Step 2: DNS turns the name into a number

Here's the first thing most people don't realise: example.com is not an address the network can use. The internet routes data using numeric IP addresses like 93.184.216.34. The human-friendly name is a convenience layered on top.

So the browser's first real network act is a DNS lookup — asking the Domain Name System, the internet's distributed phonebook, "what's the IP address for example.com?" We devote a whole chapter to DNS, because that lookup is itself a small relay race through several servers. For now: name goes in, address comes back.

Step 3: TCP opens a reliable connection

Now your device has an address. But the internet moves data as small chunks called packets that can arrive out of order, or not at all (the packet chapter explains why). To get a whole web page reliably, your browser and the server first establish a TCP connection — a negotiated agreement to track every packet, re-send anything lost, and reassemble it all in order.

TCP opens with a quick three-message handshake ("can we talk?" / "yes, can you?" / "yes"), covered in the TCP/IP chapter. Once it completes, both sides have a reliable pipe.

Step 4: TLS makes the connection private

For an https URL, one more handshake happens before any real data: TLS, the protocol that puts the S (for Secure) in HTTPS. In a few more round-trips, your browser and the server verify each other's identity and agree on encryption keys, so everything that follows is unreadable to anyone in between.

We covered TLS in depth in the security guide's HTTPS chapter — the certificates, the padlock, what it does and doesn't guarantee. Here, just note its place in the sequence: connect first (TCP), secure second (TLS), then talk.

Step 5: The HTTP request — finally, you ask for the page

Two handshakes done, your browser sends the request it was always trying to send. It's just text, and simpler than you'd expect:

GET /page HTTP/1.1
Host: example.com

That's the core of it: the method (GET — "fetch me this"), the path, and some headers. This is HTTP, the language of the web, and we cover it fully in the backend guide's HTTP chapter. The request travels — as packets, across many routers — to the server.

Step 6: The response comes back, and the page renders

The server receives the request, does its work (looks up the page, maybe queries a database), and sends back an HTTP response: a status code (200 OK), headers, and the content — the HTML of the page.

But one response is rarely the whole story. That HTML says "I also need this CSS file, these images, this JavaScript" — and your browser fires off more requests, often dozens, each potentially repeating much of this journey (though the earlier steps are now cached and fast). As the pieces arrive, the browser assembles and paints the page. You see it appear.

The whole thing, timed

What's genuinely remarkable is the scale hidden inside "the page loaded." That single Enter keypress triggered:

• Queries to servers possibly on other continents
• Data physically travelling through undersea cables at near light-speed
• A dozen independently-operated networks handing your packets along
• Multiple cryptographic negotiations
• All typically in well under a second

What's ahead

We'll build the full picture bottom-up from here, each chapter deepening one step of the relay:

Recap

• Typing a URL sets off a six-step relay: parse → DNS lookup → TCP connection → TLS handshake → HTTP request → response and render.
• The internet routes on numeric IP addresses; the human-friendly name is translated first, by DNS.
• Before any page data flows, there's a TCP handshake (reliable connection) and, for HTTPS, a TLS handshake (private connection).
• The web itself is simple underneath: an HTTP request for a resource, an HTTP response with the content — usually followed by dozens more requests for the page's pieces.
• It all completes in under a second, across many independently-run networks and physical infrastructure spanning the planet — which is what the rest of this guide unpacks.

First, the thing everything else depends on: how every device on the internet gets an address. Continue to IP addresses, explained.