What Happens When You Type a URL in the Browser

"What happens when you type a URL and press Enter?" is the classic networking interview question because it touches every layer at once: name resolution, addressing, the transport handshake, encryption, routing, the application protocol and finally the browser. A good answer is ordered, names the protocol at each step and can go deeper wherever the interviewer pushes. This note gives the thirty-second version first, then each step in detail, with links to the notes that cover each protocol in full.

The short answer

1. The browser parses what you typed into a URL: scheme, host, port, path.
2. It checks its caches: the page itself, an open connection to the site, the DNS answer.
3. DNS resolves the host name to an IP address.
4. The operating system finds the default gateway's MAC address with ARP, and the home router applies NAT.
5. A TCP connection opens with the three-way handshake (port 443).
6. A TLS handshake agrees keys and checks the server's certificate.
7. The browser sends an HTTP GET request.
8. Routers forward the packets hop by hop across the internet to the server or a CDN edge.
9. The server side (CDN, load balancer, web server, application, database) builds the response.
10. The browser receives the HTML, fetches the CSS, scripts and images it references, and renders the page.

Step 1: parsing the URL

The browser first decides whether you typed an address or a search: "example.com" looks like a host, "tcp vs udp" does not and goes to the default search engine. A URL such as https://www.example.com/products?id=7 splits into the scheme (https, hence default port 443), the host (www.example.com), the path (/products) and the query (id=7). If you typed no scheme, many modern browsers try HTTPS first. If the host is on the browser's HSTS list (built in, or remembered from a Strict-Transport-Security header on an earlier visit), the browser upgrades to HTTPS before a single packet leaves.

Step 2: checking the caches

• HTTP cache. If the page is cached and still fresh under its Cache-Control rules, the browser can show it with no network traffic at all. If it is stale but has an ETag, the browser sends a conditional request and may get a short 304 Not Modified.
• Connection reuse. If the browser already holds an open connection to this origin, it reuses it and skips DNS, TCP and TLS entirely.
• DNS caches. The browser's cache, the operating system's cache and the hosts file are checked before any query is sent.

Step 3: DNS resolution

On a miss, the operating system's stub resolver asks the configured recursive resolver (learned from DHCP) over UDP port 53. If that resolver has nothing cached, it asks a root server, then the .com TLD servers, then example.com's authoritative server, caches the answer for its TTL and returns, say, 203.0.113.10. The full walk-through is in DNS. The browser may receive both an IPv4 (A) and an IPv6 (AAAA) address and try both.

Step 4: getting the first packet out

The host compares 203.0.113.10 with its own address and subnet mask and sees that it is on another network, so the packet must go to the default gateway. The host needs the gateway's MAC address; if it is not in the ARP cache, it broadcasts an ARP request and the router answers (data link layer). On Wi-Fi the frame first goes to the access point, under CSMA/CA. The home router then performs NAT, recording each rewrite so the replies can find their way back (NAT, DHCP and ports):

1. The server is on another network, so the Ethernet frame is addressed to the home router's MAC address (found by ARP), while the IP packet inside is addressed to the server itself.
2. The home router rebuilds the frame for its next link with new MAC addresses, lowers the TTL to 63, and its NAT rewrites the private source to 203.0.113.5, port 40001. These 5 fields change.
3. At the ISP's router only the frame and the TTL change: new MAC addresses for the next link, TTL 62. The IP addresses and ports now stay fixed all the way to the server.

Step 5: the TCP handshake

The browser opens a TCP connection to 203.0.113.10 port 443 from an ephemeral port: SYN, SYN-ACK, ACK. Both sides now know each other's initial sequence numbers and receive windows, at the cost of one round trip (TCP and UDP). With HTTP/3 this step and the next merge into a single QUIC handshake over UDP.

Step 6: the TLS handshake

In TLS 1.3, the ClientHello carries supported cipher suites, a key share and the server name (SNI); the ServerHello returns the server's key share, its certificate and a signature proving it holds the certificate's private key. The browser checks that the certificate chains to a trusted authority, is in date, matches www.example.com and is not revoked. Both sides derive the same symmetric keys, one round trip after the TCP handshake (HTTP and HTTPS). A certificate error stops the browser here with a warning page.

Step 7: the HTTP request

GET /products?id=7 HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html
Accept-Encoding: gzip, br
Cookie: session=4f2a9c

Over HTTP/2 or HTTP/3 the same fields travel as compressed binary frames on a stream, and later requests for the page's resources are multiplexed on the same connection.

Step 8: across the internet

The request is split into IP packets. Every router on the way decrements the packet's TTL, looks up the destination with longest prefix match and forwards it to the next hop, rebuilding the frame for the next link as in the figure above; between ISPs, the routes were chosen by BGP (routing). traceroute shows these hops.

Step 9: on the server side

DNS may have pointed the browser at a CDN edge near you rather than the origin. Behind it, a load balancer picks one of many servers and often terminates TLS; a reverse proxy or web server (such as Nginx) serves static files and passes dynamic requests to the application server, which reads from a cache or a database and builds the HTML or JSON.

1. DNS pointed the browser at a nearby CDN edge, not the origin. The logo is in the edge's cache, so the edge answers at once and nothing behind it hears about the request.
2. The product page is dynamic: the edge passes it on. TLS ends at the load balancer, which picks a server; the app server misses in the cache for product 7 and reads the database, and the HTML returns the same way.

The response comes back with a status line (200 OK, or a 301 redirect that starts another request), headers such as Content-Type, Cache-Control and Set-Cookie, and a body, usually compressed with gzip or Brotli.

Step 10: rendering the page

The browser parses the HTML into the DOM and the CSS into the CSSOM; together they give the render tree of what is visible, which is laid out, painted and composited:

1. The HTML parser turns the markup into the DOM, a tree of element nodes, while the bytes are still arriving. Every element is in it, the head and the hidden promotion included.
2. The CSS is parsed into the CSSOM, a set of rules the browser matches against every DOM node. Here two rules hide things and two set font sizes.
3. DOM plus CSSOM gives the render tree: only what will be drawn. Rules with display: none drop head and p.promo and everything inside them, so the title and "Sale" never reach the screen.
4. Layout computes each box's position and size: the 32 px heading takes 40 px from the top, and the paragraph starts at y 40. Change a size or add text and this step, a reflow, runs again.
5. Paint fills each box with pixels, text, colours and borders, and compositing stacks the painted layers on screen. Only now does the visitor see the page.

On finding stylesheets, scripts and images, the parser requests them, reusing the connection. Ordinary scripts pause HTML parsing while they download and run, which is why pages mark them defer or async. JavaScript may then call APIs for more data and change the page.

Keep-alive and closing

The connection is not closed after the page: HTTP/1.1 keeps it alive by default and HTTP/2 multiplexes everything over it, so the next click skips DNS, TCP and TLS. After an idle timeout, either side closes it with a TCP FIN exchange.

Worked example: the timeline of a first visit

Assume the recursive resolver already has the name cached and is 10 ms away (round trip), the server is 40 ms away (round trip), the server needs 50 ms to build the page, TLS 1.3 is used and transmission time is negligible.

1. DNS first: there is nothing to connect to until the name is an address. The recursive resolver, 10 ms away, has www.example.com cached and answers 203.0.113.10.
2. The TCP handshake with the server, 40 ms away: SYN out, SYN-ACK back. The browser's ACK will ride with its next message, so the clock reads 50 ms.
3. TLS 1.3 needs one more round trip: key shares, the certificate and Finished. 90 ms have passed and not one byte of the page has been asked for.
4. The GET goes out, the server spends 50 ms building the page, and the first byte of HTML arrives at 180 ms — before any CSS or image. Over QUIC it would be 140 ms; on a reused connection, 90 ms.

The first byte of HTML arrives after about 180 ms, before any CSS or images. With HTTP/3, QUIC folds the TCP and TLS round trips into one, giving 10 + 40 + 90 = 140 ms. On a repeat visit over a kept-alive connection, only the last row remains: 90 ms. This is why CDNs (shorter round trips), connection reuse and caching matter more for page speed than raw bandwidth.

Which protocol does what

Common mistakes

• Skipping DNS, or putting it after the TCP handshake: there is nothing to connect to until the name is resolved.
• Saying the laptop ARPs for the web server: for an off-subnet destination it ARPs for its default gateway.
• Putting TLS before TCP for HTTPS over TCP: TCP connects first, then TLS runs inside it (only QUIC merges them).
• Saying the destination IP address changes at every router: only the MAC addresses change, plus NAT at the edge.
• Forgetting redirects: a 301 to the HTTPS or www address costs another full request.
• Ending at "the server sends HTML": the browser still fetches subresources and renders.

Interview questions

Why must DNS happen before the TCP handshake? TCP connects to an IP address and port, not to a name. Until DNS has turned www.example.com into an address, the operating system has nowhere to send the SYN.

Which MAC address does the first frame from your laptop carry? The default gateway's. The destination is on another network, so the laptop sends the frame to its router, found through ARP, while the IP packet inside is addressed to the web server.

What does the browser check during the TLS handshake? That the server's certificate chains to a trusted certificate authority, is within its validity period, names the requested host and is not revoked, and that the server proved possession of the matching private key by signing the handshake. Any failure produces a certificate warning.

How does a CDN make this faster? It shortens the distance for every round trip: DNS or anycast directs the browser to a nearby edge, so the TCP, TLS and HTTP exchanges cover tens of kilometres rather than thousands, and cached content is served without contacting the origin at all.

What happens if you type http:// for a site that uses HSTS? If the browser has seen the site's HSTS header before, or the site is on the built-in preload list, it rewrites the URL to https:// internally and never sends the plain HTTP request, which prevents an attacker on the network from intercepting that first request.

How are the images and scripts on a page fetched? As the HTML parser finds references to them, the browser issues more HTTP requests, normally to the same or a few other origins. Over HTTP/2 or HTTP/3 they are multiplexed as parallel streams on one connection; HTTP/1.1 browsers open several connections per host instead.

How would you debug a page that will not load? Work up the layers: check the device has an address (not 169.254), ping the gateway, resolve the name with nslookup or dig, test reachability with ping and traceroute, then fetch with curl -v to see the TLS handshake and the HTTP status. Browser developer tools show the timing of every request.

Next, read network security basics, and test the whole path with the Computer Networks (Basic) skill test.