What Actually Happens When You Type a URL and Hit Enter

"What happens when you type a URL and press Enter?" is the most-asked systems question in interviews, and for good reason: a complete answer touches DNS, transport, security, HTTP, and rendering — the whole stack a web developer stands on. Here is the journey of a single request, with enough depth to answer well and enough why to remember it.

1. The browser parses the URL

https://devpath.example/guides?topic=css breaks into a scheme (https), a host (devpath.example), an optional port (defaulting to 443 for https), a path (/guides), and a query (topic=css). The browser also checks its HSTS list — a record of sites that demand HTTPS — and may upgrade http to https before a single byte leaves your machine.

2. DNS: turning a name into an address

Computers route by IP address, not names. So the browser must resolve devpath.example to something like 93.184.216.34. It checks caches in order — browser, operating system, your router — and only on a miss does it ask a resolver (usually your ISP's or a public one like 1.1.1.1). The resolver walks the hierarchy: root servers point to the .example TLD servers, which point to the domain's authoritative nameserver, which finally returns the address. This is why a brand-new domain can take time to "propagate" — caches at each level hold old answers until their TTL expires.

3. TCP: establishing a reliable pipe

With an IP address, the browser opens a TCP connection via the three-way handshake: SYN → SYN-ACK → ACK. TCP's job is to turn the internet's unreliable packet delivery into an ordered, lossless stream. It numbers bytes, retransmits what's dropped, and reassembles everything in order so the layers above can pretend the network is perfect. (HTTP/3 swaps TCP for QUIC over UDP to cut handshake latency, but the guarantees it provides are the same.)

4. TLS: making the pipe private

Because the scheme is https, a TLS handshake runs next. The server presents a certificate — a public key signed by a Certificate Authority your browser trusts. The browser verifies that chain of trust, confirms the certificate is for this hostname and not expired, and the two sides negotiate session keys. After this, everything is encrypted and tamper-evident. This is why a valid certificate matters: it's not a formality, it's the thing that stops anyone between you and the server from reading or altering the page.

5. HTTP: the actual request

Now the browser sends an HTTP request:

GET /guides?topic=css HTTP/2
Host: devpath.example
Accept: text/html
Cookie: session=…

The server — often behind a load balancer and a CDN — routes this to application code, which may query a database, render HTML, and respond:

HTTP/2 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: max-age=3600

Status codes carry meaning: 200 OK, 301/302 redirects, 404 not found, 500 server error. A well-behaved frontend reads these instead of guessing.

6. The browser builds the page

The HTML arrives and the real frontend work begins:

• The parser turns HTML into the DOM tree and CSS into the CSSOM tree.
• It combines them into the render tree, computes layout (the geometry of every box), and paints pixels, often compositing layers on the GPU.
• Along the way it discovers more resources — CSS, JavaScript, images, fonts — and fetches each, repeating much of this entire journey for every one.

Here's the catch that defines frontend performance: a <script> without async or defer blocks parsing while it downloads and executes, and CSS blocks rendering because the browser won't paint un-styled content. Understanding this single fact explains 80% of why pages feel slow — and why "put scripts at the end" and "inline critical CSS" are evergreen advice.

7. JavaScript brings it to life

Finally, JavaScript runs: it can mutate the DOM, attach event listeners, fetch more data, and — in a single-page app — take over navigation entirely so that future "page loads" are just fetch calls and DOM updates, skipping steps 1–5 after the first visit.

Why this matters beyond interviews

Every layer is a place where things break and where you can make things faster. Slow DNS, a missing certificate, an uncached response, a render-blocking script — each is a distinct failure with a distinct fix. Developers who hold this whole picture debug in minutes what others chase for hours, because they know which layer to suspect.

You can move on when you can narrate this journey end to end and name one performance lever at each layer: DNS prefetch, connection reuse, HTTP caching, and non-blocking scripts.