What Happens When You Type a URL and Press Enter

This is the single most famous systems interview question. It is beloved because it touches every layer of the stack — parsing, DNS, TCP, TLS, HTTP, server-side processing, and browser rendering. A strong answer is a guided tour that shows how the pieces connect. Let us walk https://www.google.com/search?q=cats end to end.

Step through the whole pipeline below — each stage expands to show what actually happens:

Stage 1: Parse the URL

The browser first decomposes the URL into its parts:

scheme   = https
host     = www.google.com
port     = 443   (implied by https)
path     = /search
query    = q=cats

If the input is not a valid URL, the browser hands it to the default search engine instead. The browser also checks HSTS: if the domain is on the preloaded HSTS list, an accidental http:// is upgraded to https:// before anything leaves the machine.

Stage 2: Resolve the name (DNS)

The browser needs an IP for www.google.com. It checks caches in order before hitting the network:

1. Browser cache — recent lookups.
2. OS cache — the stub resolver / hosts file.
3. Recursive resolver (your ISP or 8.8.8.8) — which itself walks root → TLD → authoritative if not cached.

The result (say 142.250.72.196) comes back and is cached per its TTL. This typically involves a UDP round trip to the resolver.

Stage 3: Establish a TCP connection

With an IP in hand, the browser opens a TCP connection to 142.250.72.196:443 via the three-way handshake:

Client → Server:  SYN
Server → Client:  SYN-ACK
Client → Server:  ACK

Before this, the OS may need ARP to find the MAC address of the default gateway (the first hop), since the destination is on a different network. Routing then carries the packet hop by hop, each router using longest-prefix match, until it reaches Google's network.

Stage 4: TLS handshake

Because the scheme is HTTPS, the browser and server negotiate a TLS session on top of TCP:

ClientHello (ciphers, key share, SNI = www.google.com)
ServerHello (chosen cipher, key share) + Certificate + Finished
Client Finished

The browser validates the server's certificate chain up to a trusted root CA, checks expiry and that the domain matches, and both sides derive a shared session key (with forward secrecy via ephemeral Diffie–Hellman). TLS 1.3 needs just one round trip. After this, everything is encrypted.

Stage 5: Send the HTTP request

Inside the encrypted tunnel, the browser sends the request:

GET /search?q=cats HTTP/2
Host: www.google.com
User-Agent: Mozilla/5.0 ...
Accept: text/html,application/xhtml+xml
Cookie: ...

For a repeat visit the browser may include cache-validation headers like If-None-Match (ETag) or If-Modified-Since, which can yield a cheap 304 Not Modified.

Stage 6: The server processes the request

On the other side, the request usually lands on a load balancer first, which picks a healthy backend. That backend may hit application logic, a cache (Redis), and a database, then assemble a response. Frequently a CDN edge near the user serves static assets or even the whole page without reaching the origin. The server returns:

HTTP/2 200 OK
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Cache-Control: private, max-age=0

Stage 7: The browser renders the page

Now the browser turns bytes into pixels:

1. Parse HTML into the DOM tree.
2. Parse CSS into the CSSOM; combine with the DOM into the render tree.
3. Layout (reflow) — compute the geometry of every box.
4. Paint — fill in pixels; composite layers to the screen.
5. As the parser hits <img>, <script>, <link> tags, it fires more HTTP requests for those subresources — often reusing the same connection (HTTP/2 multiplexes them). Blocking scripts pause parsing unless marked async/defer.

The page becomes interactive once critical scripts run and the main thread is free.

The one-line map

URL parse → DNS → TCP handshake → TLS handshake → HTTP request →
   LB/CDN/app/DB → HTTP response → parse (DOM/CSSOM) → layout → paint → subresources

Common follow-ups

• "Where could this be faster?" DNS prefetch, TCP/TLS session resumption (0-RTT), CDN edge caching, HTTP/2 multiplexing, gzip/brotli compression, and keeping critical CSS inline.
• "What if DNS fails?" The browser shows a resolution error; there is no IP to connect to.
• "Why HTTPS everywhere?" Confidentiality, integrity, authentication — and browsers now gate features (HTTP/2, service workers) behind it.
• "HTTP/1.1 vs HTTP/2 here?" HTTP/2 multiplexes many subresource requests over one connection, avoiding HTTP/1.1 head-of-line blocking at the application layer.

In the interview

1. Give the ordered pipeline first, then zoom into whichever stage they probe.
2. Do not forget the caches — browser/OS/resolver DNS caches and HTTP caching (304) show depth.
3. Mention ARP and routing briefly to prove you know layer 2/3, not just the application layer.
4. End with rendering (DOM → CSSOM → layout → paint) — many candidates stop at the response and lose points.