You type a URL into the address bar and hit Enter ── or click a link ── and the page appears in under a second. It’s so ordinary you’ve probably never given it a thought. But behind that instant, your PC completes a long journey: it borrows an address, looks up a phone book, entrusts a package, passes a checkpoint, and receives an answer relayed through towns all over the world. If any of these ring a bell, read on.
- “Explain what happens between typing a URL and the page being displayed” ── the classic IT interview and exam question left you speechless
- Your understanding stops somewhere around “DNS does… something“
- When a page is slow, you’d like to be able to guess which part is slow
- You’ve read the individual deep-dives, but want a single article that shows how it all connects
This article follows the work your browser does behind the scenes as the round trip of a single request (a letter carrying your question) ── chronologically, from the pre-departure preparations to pixels on the screen. Let’s lay out the whole itinerary up front.
- 0Pre-departure prepYour PC is already a “town resident” ── address, exit, and phone-book location all borrowed.
- 1From name to addressThe phone book (DNS) turns example.com into an address (an IP address).
- 2Leaving townSorting clerk (switch) → town exit (router) → translation desk (NAT) → checkpoint (firewall).
- 3Relayed across the worldTown to town, routers read the destination and pass the package along.
- 4The answer comes homeThe reply follows the ledger entry left on the way out, all the way back to your PC.
- 5Pixels on the screenThe browser reads the blueprint (HTML) and renders, fetching missing materials as it goes.
Every character in this story has its own deep-dive article on this site. This article stays out of the weeds and traces, by the shortest route, only the connections ── who works, in what order, and why. Whenever a step catches your eye, dive into the matching article from there.
| Question | Where it’s covered |
|---|---|
| What’s the very first thing that happens after I type a URL? | §1・§2 |
| How does the package actually get out of the house? | §3 |
| Why does the answer find its way back to my PC? | §4 |
| Why are some pages fast and others slow? | §5 |
| Asked to explain the whole thing in one go? | FAQ Q5 |
This article is the grand recap of our “How PCs Work” series (IP addresses, DNS, firewalls, why office networks get slow, VPN, NAT, DHCP, switches and routers). The characters from those eight articles all appear here ── in network order of appearance.
1. Step Zero: Pre-Departure Prep ── Your PC Is Already a “Town Resident”
1-1. The journey starts before the Enter key
Most explanations open with “first, DNS…” ── but some preparation finished before that. The moment your PC joined the Wi-Fi, it borrowed a four-item kit from the building manager (DHCP) (→ What is DHCP?).
Pre-departure inventory ── the four-item kit borrowed from DHCP ┌── what your PC is carrying ───────────────────────────────┐ │ │ │ 1. Its own address (IP address) │ │ 2. The neighborhood boundary (subnet mask) │ │ 3. Where the town exit is (default gateway) │ │ 4. Where the phone book is (DNS server address) │ │ │ │ => these four are the packing list for the journey ahead │ └───────────────────────────────────────────────────────────┘
Without an address of its own, it can’t receive a reply. Without the neighborhood boundary, it can’t judge whether a destination is “in town or out of town.” Without knowing where the exit is, it can’t leave town; without knowing where the phone book is, it can’t turn names into addresses ── in other words, every step of the journey ahead is possible precisely because these four items are in place.
From here on, this article picks each item back up at the moment it gets used: item 4 in §2, items 2 and 3 in §3, and item 1 in §4. Keep the packing list in the back of your mind ── and let’s set off.
2. From Name to Address ── Looking It Up in the Phone Book (DNS)
2-1. The part of the URL the machines need is the name
A URL like https://example.com/page is built from three parts. https:// is “the etiquette we’ll speak with,” example.com is “the name of the other party,” and /page is “which page inside.” The journey’s first gate is the middle one: the name.
That’s because the network’s delivery system runs not on names but on addresses (IP addresses) (→ What is an IP address?). Names that humans can remember, addresses that machines deliver by ── bridging those two is the very first thing that has to happen.
2-2. Ask the phone book ── but not every single time
So the PC turns to item 4 of its kit ── the phone-book location ── and asks: “Could I have the address for example.com, please?” That phone-book service is DNS. The lookup’s own journey (your local notes → the town’s phone book → the worldwide phone-book network) gets the full treatment in What is DNS?, so here, remember just one thing: once a name has been looked up, it’s jotted down for a while, and next time nobody goes asking again (caching) ── reason number one the same site opens faster on a second visit.
We have an address. example.com = 93.184.216.34, say. The journey’s destination is locked in.
Matching the https:// at the front of the URL, a padlock icon appears in the address bar. It’s a declaration: “this exchange of letters travels in a sealed, encrypted envelope.” How nobody along the way can open that envelope is a whole article of its own ── for now, just note “it’s sealed” and keep moving.
3. Leaving Town ── the Sorting Clerk, the Town Exit, the Translation Desk, and the Checkpoint
3-1. The first fork: is the destination in town, or out of town?
With the destination set, the PC makes one judgment before sending the package (the request) on its way: is this destination in the same town (the same network), or out of town? The yardstick is kit item 2, the subnet mask (the neighborhood boundary). 93.184.216.34 is clearly out of town ── so the package is bound for kit item 3: the town exit (the default gateway, i.e., the router) (→ how that judgment works: Switch vs router: what’s actually different? §1).
In-town delivery is the job of the sorting clerk (the switch). The clerk reads the nameplate on the door (the MAC address) and hands the package reliably to the exit’s room ── everything up to this point has happened inside the house.
3-2. Two procedures at the exit ── an address rewrite and an inspection
At the town exit (the router), the package goes through two procedures.
First, the translation desk (NAT) rewrites the sender’s address. Your PC’s address is for in-town use only (a private IP), so it can’t go out into the world as-is. The desk rewrites the sender field to the town’s public mailing address (the global IP) and records “which room this package left from” in a ledger (the NAT table) (→ What is NAT?). That ledger becomes the key to the way home ── we’ll collect on it in §4.
Second, the checkpoint (firewall) inspection. Outgoing and incoming packages are checked against the rules here (→ What happens without a firewall?). You never notice it, but on both legs of this journey, the package always passes in front of the checkpoint.
Your PC not knowing its own global IP is not a malfunction. The public address gets attached for the first time at the town exit, so the PC itself only ever knows its in-town address. That’s the answer to the mystery of “the what’s-my-IP website and my PC’s settings screen show two different addresses.”
On a company PC connecting to internal systems, one more detour can slot in before the exit ── the package gets pulled into an encrypted tunnel first: a VPN. Why the tunneled journey gets slow is covered in Why is the office network so slow? §4.
4. Relayed Across the World, and the Answer Comes Home
4-1. The internet = a chain of towns. Router to router
Once out of town, the package doesn’t teleport to its destination. The internet is a chain of towns, and each town’s exit (router) reads the destination, judges “the next town over is closer,” and passes it to the neighbor ── this relay (routing) repeats a few dozen times until the package reaches the town of 93.184.216.34 (→ Switch vs router: what’s actually different? §4).
The far end mirrors ours. Their town has a checkpoint (firewall) too, and only packages that pass inspection reach the building ── the server that keeps the page’s data. The server reads the request (“/page, please”), builds the answer package, and sends it back. “What exactly is a server, anyway?” is a fascinating topic in its own right ── we’ll save it for another article.
4-2. The mystery of the way home ── why does the answer reach your PC?
Here’s the question most explanations skip. The answer package is addressed to the town’s public mailing address. The town is full of devices ── so why does the package find its way back to your PC, specifically?
The key is the ledger (NAT table) the translation desk filled in back in §3. When the answer arrives, the desk looks the entry up in reverse ── “this package is the reply to that room’s question” ── and rewrites the destination back to the in-town address. From there, the sorting clerk (switch) reads the nameplate and hands it to your PC’s room ── the same checkpoints as the way out, passed in the opposite direction (→ how the ledger works: What is NAT? §3).
The full round trip ── the same checkpoints, passed in opposite directions
Outbound (the request)
PC => sorting clerk => town exit ┌ translation desk: rewrite sender to public address + record in ledger
└ checkpoint: inspection
=> town => town => town … (the router relay) => their checkpoint => server
Return (the answer)
server => their checkpoint => … town => town => town => town exit
┌ checkpoint: inspection
└ translation desk: reverse-lookup the ledger, rewrite destination
=> sorting clerk => PC (journey complete)
5. From Delivery to Display ── the Browser’s Job
5-1. What came back is a blueprint ── one page ≠ one package
The package that came home contains not the page itself but a blueprint (HTML). The browser reads the blueprint top to bottom and starts assembling ── “an image goes here,” “looks follow this style sheet (CSS),” “behavior follows this script (JS)” ── and every time it notices a missing material, it runs the whole §2–§4 journey again to fetch it.
In other words, behind a single page load, the same round trip runs dozens of times. “Typing one URL = one journey” was never the deal ── it’s a bundle of journeys. That’s this article’s final reveal, and it explains both why image-heavy pages load slowly and why a page sometimes renders with pieces missing: it comes down to how many journeys there are and which ones succeed.
5-2. Why the second visit is faster ── the warehouse, and journey’s end
Materials fetched once go into the browser’s local warehouse (the cache) for a while. The more materials a second visit can skip the journey for entirely, the faster the page opens ── put that together with §2’s phone-book notes, and the “second time is faster” mystery is fully solved. The “I updated the page but nothing changed” incident, caused by a stale warehouse, is a whole article of its own ── consider this the setup.
All the materials arrive, the screen gets painted, and the journey is over. From the Enter key to here: one or two seconds at most ── here’s that opening timeline, one more time.
- 0Pre-departure prepYour PC is already a “town resident” ── address, exit, and phone-book location all borrowed.
- 1From name to addressThe phone book (DNS) turns example.com into an address (an IP address).
- 2Leaving townSorting clerk (switch) → town exit (router) → translation desk (NAT) → checkpoint (firewall).
- 3Relayed across the worldTown to town, routers read the destination and pass the package along.
- 4The answer comes homeThe reply follows the ledger entry left on the way out, all the way back to your PC.
- 5Pixels on the screenThe browser reads the blueprint (HTML) and renders, fetching missing materials as it goes.
Recap ── 6 Steps, Plus a Map for the Deep Dives
- Pre-departure prep ── the PC has borrowed address, boundary, exit, and phone-book location from DHCP (the building manager); it’s already a town resident
- From name to address ── the phone book (DNS) turns the name into an address (IP); once looked up, it’s jotted down and skipped next time
- Leaving town ── the boundary says “out-of-town” → the sorting clerk (switch) hands the package to the exit → the translation desk (NAT) rewrites the sender to the public address and records it in the ledger → the checkpoint (FW) inspects
- Relayed across the world ── town exits (routers) read the destination and pass the package along, through the far checkpoint, to the server
- The answer comes home ── a reverse lookup in the ledger rewrites the destination back, and the reply passes the outbound checkpoints in reverse, to the PC
- Pixels on the screen ── the browser reads the blueprint (HTML), repeats the journey for each missing material, stocks the warehouse (cache), and paints
| Step | Who’s working | Deep dive |
|---|---|---|
| 0. Pre-departure prep | Building manager (DHCP) | What is DHCP? |
| 1. From name to address | Phone book (DNS) · mailing address (IP) | What is DNS? · What is an IP address? |
| 2. Leaving town | Sorting clerk · town exit · translation desk · checkpoint | Switch vs router · What is NAT? · What happens without a firewall? |
| 3–4. The relay and the way home | Routers · the translation desk’s ledger | Switch vs router · What is NAT? |
| 5. Pixels on the screen | The browser | ─ (caching and HTTPS in future articles) |
| When something along the way is slow | ─ | Why is the office network so slow? · What is a VPN? |
FAQ
Q1. When a page is slow, can I tell which step is the slow one?
A. Roughly, yes (see the timeline in §0). If every site is uniformly slow, suspect the §3–4 route (your line, a VPN, the office network). If only the first beat is slow, suspect §2’s name lookup. If specific images or parts of one page lag, suspect §5’s material-fetching journeys. For serious triage on an office network, Why is the office network so slow? is the hands-on companion.
Q2. What’s different when I type keywords into the search bar instead of a URL?
A. Almost nothing. The only difference is that one extra “same journey, but to the search engine” runs first. The moment you click a result link, §1–§5 of this article play out exactly as written. And if you type keywords straight into the address bar, the browser quietly rewrites them into a search-engine URL ── then takes the same journey.
Q3. Does the same thing happen with bookmarks, or with smartphone apps?
A. It does. A bookmark merely skips the “type the URL” part ── the journey itself starts from step zero, unchanged. Smartphone apps don’t look like browsers, but behind the scenes they talk to their servers via the same round trip (name lookup → leave town → relay → the way home). They borrow the four-item kit from the building manager the moment they join the Wi-Fi, too.
Q4. Can anyone read the package’s contents along the way?
A. If the connection starts with https:// (the padlock icon), the package travels in an encrypted envelope ── the routers and checkpoints of the towns along the way can’t read the contents. All they can read is the destination on the outside. How that envelope works ── why nobody along the route can produce a seal-breaking key ── is a whole article of its own, planned for a future post.
Q5. Asked to “explain everything from URL to display in one go” ── how should I answer?
A. Here’s this article’s six steps compressed into a 30-second model answer ── “First, the PC has already obtained its IP address and related settings from DHCP. When the URL is entered, ① DNS resolves the domain name to an IP address; ② the destination is judged to be on an external network, so the packet goes via a switch to the default gateway; ③ at the router, NAT translates the source address and the firewall inspects the traffic; ④ the packet is relayed router-to-router by routing until it reaches the server; ⑤ the server’s response returns to the original device via a reverse lookup of the NAT table; and ⑥ the browser parses the HTML and renders the page, issuing additional requests for images, CSS, and other assets as it goes.” ── If anyone digs into a step, this article’s matching section and the linked deep dives have you covered.
Leave a Reply