What happens when you type a URL

You press Enter and, for a moment, nothing happens — a couple hundred milliseconds on a good connection, but a real gap, and the only part of this question worth answering. This is the oldest interview question there is, and it survives because it has no bottom. The video walks the chain and stops at the first painted pixel. Here’s the rest, and the one line most answers get wrong.

#	The question being answered	Machinery
0	Which scheme am I even using?	HSTS
1	What number goes with this name?	DNS
2	Can I get bytes to that number, reliably?	ARP, IP, TCP
3	Can anyone else read them?	TLS
4	What do I want?	HTTP
5	What is this supposed to look like?	Parse, style, layout, paint

Steps 1 and 2 are the ones people merge, and merging them is the whole subject of this post.

0. The URL you typed is not always the URL it fetches

Before anything leaves your machine, the browser decides what it’s actually fetching. If a host has previously sent Strict-Transport-Security: max-age=63072000, that’s HSTS (RFC 6797), and for max-age seconds the browser rewrites the URL to https itself, before a request is ever made — no redirect, no plaintext round trip an attacker on the café Wi-Fi could rewrite. The obvious hole is your very first visit to a site, before the browser has ever heard of it — the header can only protect you once it has already arrived, over a connection that was already safe. For a preloaded host, shipped inside the browser at build time, there was never a plaintext request to intercept in the first place, even on that first visit.

1. A name is not an address

Nothing on the network is called by the name you typed — RFC 1034 §2.2 makes that a design goal, not an accident: names should not be required to contain addresses. Something has to go look it up, every time.

Your machine checks caches it already holds, then asks a recursive resolver, which walks the tree on your behalf: root, then the registry for .com, then the zone’s own nameserver — each answer a referral, not a result, until the last one says “here’s the record.” Almost none of that walk happens on a normal request, because every answer along the way is cached for its TTL, including the failures (RFC 2308) — which is why a typo’d hostname in a hot loop is a denial-of-service attack on somebody’s nameserver, and why your DNS change looks half-finished for as long as the old record’s TTL runs. The mechanics of that walk, and the record types involved, are their own post.

2. An address is not a connection

Here’s the conflation this question exists to catch. “DNS resolves it and then you get the page” sounds right and isn’t. Knowing where a machine is and being able to talk to it are different achievements, separated by a handshake — you can hold a perfectly correct IP address for a host that never answers you. An address is a lookup result. A connection is shared state on two machines, and it has to be created. Say that sentence in an interview and you’ve answered the question that was actually being asked.

Getting a frame onto the wire at all takes ARP (resolving the next hop’s link-layer address, usually your router’s) and IP forwarding, hop by hop, with no router knowing the whole route. Then TCP’s three-way handshake — SYN, SYN-ACK, ACK — and the thing in those packets isn’t a greeting, it’s numbers: each side picks a starting sequence number the other can’t predict, and RFC 9293 §3.4.1 gives the reason for three messages and not two in one line: “sequence numbers are not tied to a global clock in the network.” Two messages proves one direction heard the other’s number; three proves both did. Everything TCP does afterwards — ordering, retransmission, duplicate detection — depends on both ends agreeing where the counting started.

The connection doesn’t start fast, either: TCP has no idea what the path can carry, so it probes with a small window that roughly doubles every round trip. A 60 KB HTML file is several round trips after the handshake, not one — which is why latency beats bandwidth for page loads, and why a fibre line to another continent still feels slow.

3. Trust, in one round trip

Everything so far is readable by anything on the path. TLS 1.3 (RFC 9846) fixes that in one round trip: the client guesses a key-exchange group and sends its share in the very first message, the server replies with its own share, its certificate, and a signature over the handshake — and can already send application data back. TLS 1.2 needed two round trips, because the client had to be told the parameters before it could contribute a share; that’s the round trip 1.3 removed.

The certificate proves less than people think: only that whoever is on the other end holds the private key for a name a CA your browser already trusts was willing to vouch for. Not that the site is honest — just that it’s the name you asked for. And one thing stays in the clear even here: the ClientHello, including the server name you’re asking for, because encryption only starts after the key exchange.

4. The request, and the page that isn’t there yet

After all of that, what you’ve been waiting to send is about forty bytes:

GET / HTTP/1.1
Host: example.com

The Host header isn’t decoration — RFC 9110 §7.2 requires it because one IP address serves thousands of sites, and the connection alone can’t say which one you meant. What comes back is text too:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 61234

— a status line and a handful of headers in front of a byte stream with no page in it yet. The browser parses it into a DOM, builds a CSSOM from the styles, combines the two into a render tree of only the boxes that will be drawn, paints those boxes into pixels, and composites the layers together — often on the GPU, which is why animating transform is smooth and animating top triggers the expensive steps all over again. Parse and style are specified; layout, paint and compositing are convergent engine design, not a standard.

What repeats for the next sub-resource on the same origin is just the HTTP request — the connection, the TLS session and the DNS answer are all reused. What starts the whole chain over is a different origin: the font from one CDN, the script from another, each paying its own DNS lookup, handshake and slow start from zero. That’s why third-party domains are expensive for structural reasons, not stylistic ones — and increasingly, over HTTP/3, steps 2 and 3 aren’t even two separate round trips, because QUIC folds the transport and TLS handshakes into one.