What happens when you type a URL?
The most-asked tech interview question, animated. Five chapters take you from keystroke to pixels: DNS, TCP, TLS, HTTP, and Render. Pace it yourself — nothing autoplays.
Animated explanation of what happens when you type a URL into a browser — DNS resolution, TCP three-way handshake, TLS handshake, HTTP request and response, and browser render pipeline. Step-by-step interactive lesson built for IT students and engineers preparing for system design interviews.- ·What an IP address roughly is (a number that identifies a machine)
- ·Comfortable opening a browser and typing a URL
- ·Bonus: rough idea of what 'a server' is
Explain — to yourself, to an interviewer — every layer that runs between pressing Enter and the page appearing. Five chapters, pace yourself.
pace: 10 minutes total
Names get turned into IP addresses. The resolver does this for you in a single recursive query, but behind the scenes it walks the DNS tree from root → TLD → authoritative server.
Before anything moves — names vs IPs
You typed example.com and hit enter. But networks don't actually use names — they use IP addresses (like 93.184.216.34). DNS (Domain Name System) is the giant distributed phonebook that turns names into IPs. Your browser asks a helper called a 'resolver' to do that lookup.
DNS is hierarchical. Every dot in a domain name is a delegation boundary. example.com is delegated by .com which is delegated by the root.
Read this lesson as text24 chapters · quiz answers
01DNS · Before anything moves — names vs IPs
You typed example.com and hit enter. But networks don't actually use names — they use IP addresses (like 93.184.216.34). DNS (Domain Name System) is the giant distributed phonebook that turns names into IPs. Your browser asks a helper called a 'resolver' to do that lookup.
02DNS · Browser → resolver: 'what's the IP for example.com?'
The browser sends the question to its configured resolver — often a public one like Cloudflare's 1.1.1.1, Google's 8.8.8.8, or your ISP's. The resolver does ALL the work of finding the answer and just hands the IP back. (In DNS jargon: this is a 'recursive' query — one question, one answer.)
03DNS · Resolver → root: 'who handles .com?'
The resolver doesn't know example.com off the top of its head — but it always knows where to start: the 13 'root' DNS servers (run by various organizations, scattered worldwide). It asks: 'who handles .com domains?' The root replies with the IPs of the .com authority servers.
04DNS · Resolver → .com authority: 'who handles example.com?'
Armed with the .com authority's address, the resolver asks it: 'who's in charge of example.com?' The .com server replies with the nameservers responsible for that specific domain (e.g. ns1.example.com, which the domain's owner configured).
05DNS · Resolver → example.com authority: 'what's the IP?'
Final hop. The resolver asks example.com's own nameserver for the actual IP address. The nameserver replies: 93.184.216.34.
06DNS · Resolver → browser: 93.184.216.34 (and cache!)
The resolver hands the IP back to the browser. It also CACHES the answer for a while (the time-to-live, or TTL, is set by the authority) so the next time anyone asks for example.com it can reply instantly. Now the browser knows where to send the next packet — onward to TCP.
07TCP · Two computers, two states
Before any conversation, the client is CLOSED and the server is LISTEN-ing on a port (port 443 for HTTPS). To exchange data reliably, they need to agree on starting sequence numbers — that's the handshake.
08TCP · Client → server: SYN seq=1000
The client picks a random sequence number x (here 1000) and sends a SYN packet. SYN means 'synchronize'. State changes to SYN_SENT.
09TCP · Server → client: SYN-ACK seq=5000 ack=1001
The server picks its own sequence number y (5000) and replies with both SYN and ACK flags. ACK=1001 acknowledges 'I received your seq 1000, expecting 1001 next'. Server is now SYN_RCVD.
10TCP · Client → server: ACK ack=5001
Client acknowledges the server's sequence number. Both sides now agree on the starting positions. Both transition to ESTABLISHED. The TCP stream is open.
11TCP · ESTABLISHED — ready for data
From here on, every byte gets a sequence number and every chunk gets ACK'd. The handshake cost ~1 round-trip; now real payload can flow. Next chapter: TLS sets up encryption on top of this stream.
12TLS · Why TLS — plain TCP is readable
TCP delivers your bytes reliably and in order, but anyone sitting on the network path (cafe wifi, ISP, etc.) can read them as they pass. TLS (Transport Layer Security — the 'S' in HTTPS) wraps the TCP stream in encryption AND proves the server is who it claims to be. The whole handshake below sets that up.
13TLS · Client → server: 'Hi, here's what I can speak'
The client opens with a ClientHello message. It lists the TLS versions it supports (modern is 1.3), the encryption algorithms it can use (called 'cipher suites'), and a random number it just generated. Think of it as: 'I speak TLS 1.3, here's my list of preferred ciphers, and here's a random number for us to use later'.
14TLS · Server → client: 'OK, here's my certificate'
The server picks one cipher suite from the client's list, sends its OWN random number, and attaches its TLS certificate — a digitally signed document saying 'I am example.com'. The signature was made by a Certificate Authority (CA) the client already trusts (the list of trusted CAs ships with your OS and browser). The client checks the signature is valid and the certificate matches the hostname.
15TLS · Both sides derive the same secret key
Now the clever bit. Both sides run a key-exchange algorithm (modern: Elliptic Curve Diffie-Hellman, abbreviated ECDHE). They each generate a temporary key pair and send the public half to the other. From those public values plus their own private half, they each independently compute the SAME shared secret. An eavesdropper sees the public values but cannot derive the secret — that's the math magic.
16TLS · Encrypted channel up
Both sides send a 'Finished' message encrypted with the new shared key. If the other side can decrypt it correctly, both know they derived the same secret and the channel is real. From this point on, every byte (the HTTP request in the next chapter, the response, everything) is encrypted with that session key. TLS 1.3 finishes this whole handshake in one round-trip; TLS 1.2 needed two.
17HTTP · Encrypted tunnel ready
We now have a private, authenticated, reliable byte-stream. Time for the actual conversation — HTTP.
18HTTP · Client → server: GET / HTTP/1.1
Client sends an HTTP request. The request line, headers (Host, User-Agent, Accept), and an empty body. All encrypted inside TLS.
19HTTP · Server → client: 200 OK + HTML body
Server responds: a status line (200 OK), response headers (Content-Type, Content-Length, Cache-Control...), then the HTML body. Still all inside TLS.
20HTTP · Sub-resources fetched in parallel
The HTML references CSS, JS, images, fonts. The browser opens additional requests (often reusing the same TCP/TLS connection) to fetch them — these can run in parallel.
21Render · Bytes arrive — parsing begins
As HTML bytes stream in, the browser's HTML parser is already running. It builds the DOM tree token by token, without waiting for the full document.
22Render · DOM tree + CSSOM
HTML becomes the DOM. CSS (inline + external) becomes the CSSOM — a parallel tree of style rules. JS that runs during parse can modify both.
23Render · Render tree → layout
DOM × CSSOM = render tree (only visible nodes with their computed styles). Layout walks this tree and assigns every box a position and size — the 'reflow' phase.
24Render · Paint + composite — pixels on screen
Each box becomes draw commands (fills, strokes, text glyphs, images). The compositor stacks layers (think CSS transforms, fixed elements) and pushes them to the GPU. You finally see the page.
Quiz — answers
- What does DNS turn a domain name like example.com into?
- →An IP addressDNS is the phonebook — name → IP address (e.g. 93.184.216.34).
- What does TCP's three-way handshake actually accomplish?
- →Both sides agree on starting sequence numbers — that's what makes the stream reliable and orderedEncryption is TLS; lookup is DNS; HTTP is the actual request. TCP's job is reliability + ordering.
- In the TLS handshake, why is the server's certificate important?
- →It proves the server's identity — a trusted Certificate Authority signed it saying 'this is example.com'Certificates are about IDENTITY, not encryption. The signature chain ensures you're talking to the right server.
- After TLS is set up, what's actually inside those encrypted bytes flowing between client and server?
- →HTTP request/response messages (request lines, headers, body)TLS wraps HTTP. Without TLS, HTTP is just plain text — you could read it with tcpdump.
- Before the browser can paint pixels, what intermediate structure does it build from the HTML?
- →DOM tree (and CSSOM from the CSS)HTML → DOM tree. CSS → CSSOM. They combine into a render tree which gets laid out and painted.
keep going — these pair well with what you just learned.
OSI / TCP-IP layers
A packet wrapped layer-by-layer, then unwrapped on the other side. Watch headers stack and peel off — OSI 7 and TCP/IP 4 side by side.
DNS deep dive
Beyond the basics: recursive vs iterative, cache layers, TTLs, glue records, and what `dig +trace` actually shows.
NAT and routing
How packets cross networks. Source NAT, destination NAT, conntrack, routing tables — visualized with real IPs.