What Happens When You
Type a URL in Your Browser?
The single most famous interview question in computer science. Follow a single packet from your keyboard, through DNS, TCP, encryption, load balancers, and servers — until pixels appear on your screen.
Follow the Packet Across the System
You type https://www.google.com and press Enter. The browser splits this URL into parts — the protocol (https), the website name (www.google.com), and the port (443). It also checks its HSTS safety list to make sure the connection will be encrypted, even on public Wi-Fi. No network request has happened yet — this is all local.
🔍 1. You Type a URL and Hit Enter
The moment you press Enter, your browser does two things before sending anything over the internet:
Step 1 — URL Parsing: The browser splits the URL into its parts. The protocol (https) tells it to use encryption. The website name (www.google.com) tells it which server to contact. The port (443) is like a door number on that server — port 443 is the standard door for encrypted traffic.
Imagine you're at a coffee shop using public Wi-Fi. If you type google.com without the https://, your first request would go unencrypted — meaning anyone on that Wi-Fi could read it. To prevent this, browsers keep a safety list of websites that should always use HTTPS. Google is on that list. So even if you forget to type https://, the browser adds it automatically. This all happens locally on your laptop — no network request has been made yet.
📮 2. DNS — Converting the Website Name to a Number
Your laptop knows it wants to talk to www.google.com, but the internet doesn't understand names — it only understands numbers called IP addresses (like 142.250.190.46). So the browser needs to look up the number for that name. This is called DNS resolution.
It's exactly like looking up a phone number in a phonebook. You know the person's name, but you need their number to call them. DNS is the internet's phonebook.
Key insight: This lookup doesn't happen every time. Once your browser learns the IP address, it remembers it (caches it) for minutes to hours. So the next time you visit Google, it skips this entire step!
📡 3. Leaving Your Wi-Fi Network (ARP Protocol)
Your laptop now knows the IP address 142.250.190.46. But Google's server is on the other side of the world — not on your local Wi-Fi network. So the packet needs to leave your home network first.
Your laptop checks: "Is 142.250.190.46 on my local Wi-Fi network?" It compares the IP against its own network range (like 192.168.1.x). Since Google's IP is clearly outside that range, the laptop knows it needs to send this packet to its Wi-Fi router (the default gateway), which will forward it to the internet.
Devices on Wi-Fi identify each other by MAC addresses (physical hardware IDs). Your laptop shouts to the entire network: "Who has IP 192.168.1.1? Tell me your MAC address!" Your router replies: "That's me! My MAC is AA:BB:CC:11:22:33." Now the packet gets wrapped in an envelope addressed to the router and is sent over the Wi-Fi radio waves.
🤝 4. Building a Secure Connection (TCP + TLS)
Before your browser can send any actual data (like "search for system design"), it first needs to establish two things with Google's server: (1) a reliable connection and (2) encryption.
Why two handshakes? The TCP handshake (steps 1–3) makes sure both sides are awake and ready — like saying "Hello" on a phone call. The TLS handshake (steps 4–5) sets up encryption — like switching to a private line so nobody can eavesdrop. After this, everything is encrypted and your actual search query can be sent safely.
The TCP handshake takes 1 round trip (your message goes to Google and a reply comes back). TLS 1.3 also takes 1 round trip. If Google's server is 50 milliseconds away, the total setup time is about 100ms — one tenth of a second. After that, data flows freely.
🏢 5. Inside Google's Datacenter
Your encrypted search request has arrived at Google's datacenter. Now it passes through three layers:
If you're loading an image, CSS, or JavaScript — the CDN (Content Delivery Network) can serve it from a server near you, without going to the main datacenter. Think of it as a local warehouse that stores copies of popular items near your city. Response time: <5ms.
Google has thousands of servers. The Load Balancer is like a receptionist — it looks at your request and decides which server should handle it. It spreads traffic evenly so no single server gets overwhelmed and crashes.
The server first checks the Cache (super fast temporary memory) — if your search was done recently, the answer is already there (~100 nanoseconds). If not, it queries the Database (permanent storage, ~10 milliseconds). It builds the HTML response and sends it back.
🎨 6. Painting the Page on Your Screen
Google's server sends back HTML and CSS code. Your browser now needs to turn that code into the actual visual page you see. This happens in 5 steps:
In plain English: The browser reads the HTML to figure out what is on the page (headings, paragraphs, images). Then it reads the CSS to figure out how it looks (colors, fonts, spacing). It combines them into a "Render Tree" — only including things that are actually visible. Then it calculates where everything goes on screen (Layout), and finally draws the actual colored pixels (Paint).
The whole process — from pressing Enter to seeing the Google search page — takes about 200–500 milliseconds. That's less than half a second. DNS lookup (~20ms) + TCP handshake (~50ms) + TLS handshake (~50ms) + Server processing (~30ms) + Data transfer (~50ms) + Browser rendering (~100ms) = ~300ms total.
🎯 7. Test Your Understanding
An interviewer asks: "When a user in London visits google.com, does their laptop query the Root DNS servers every single time?"
Why does putting a heavy <script src="bundle.js"> tag in the HTML <head> freeze the page from rendering?
Full Deep-Dive Locked
This production architecture deep-dive, interactive canvas labs, and 5-language code templates require an active Pro Pass ($1/mo or $49 lifetime).