What Happens When You Type a URL Into Your Browser?

When you type a URL and press Enter, the browser parses the address, resolves the domain to an IP address with DNS, opens a connection using TCP or QUIC, secures it with TLS, sends an HTTP request, and then renders the response into pixels. Along the way, caches, CDNs, load balancers, and application servers each do part of the work. Understanding what happens when you type a URL is one of the best ways to connect networking, backend, and frontend knowledge into a single mental model.

Here is the journey in order, using https://shop.example.com/products?page=2 as the example.

Step 1: The browser parses the URL

First, the browser decides whether you typed a URL or a search term. If it is a URL, it splits it into parts:

The browser also checks its HSTS list. If the domain is marked HTTPS-only, a typed http:// is upgraded to https:// before any request leaves the machine.

Step 2: DNS resolution turns the name into an IP

Computers route packets to IP addresses, not names, so the browser needs an IP for shop.example.com. It checks several caches in order:

1. The browser's own DNS cache.
2. The operating system's resolver cache (and the hosts file).
3. The configured recursive resolver, usually run by your ISP, company, or a public DNS provider.

If the recursive resolver has no cached answer, it walks the hierarchy: a root server points it to the .com servers, which point it to the authoritative name servers for example.com, which return the final record. Each answer carries a TTL that controls how long it can be cached. The DNS guide covers record types and caching in detail.

You can watch this yourself:

# Follow the full resolution path from the root
dig +trace shop.example.com

# See connection, TLS, and HTTP timings for a single request
curl -o /dev/null -s -w "dns=%{time_namelookup}s connect=%{time_connect}s tls=%{time_appconnect}s ttfb=%{time_starttransfer}s\n" https://shop.example.com/

For sites behind a CDN, the DNS answer often points to a nearby edge location rather than the origin server.

Step 3: Opening a connection with TCP or QUIC

With an IP address in hand, the browser opens a transport connection.

TCP

For HTTP/1.1 and HTTP/2, the browser uses TCP. The three-way handshake (SYN, SYN-ACK, ACK) establishes a reliable, ordered byte stream. That costs one round trip before any application data can flow.

QUIC and HTTP/3

If the server advertises HTTP/3 support, the browser can use QUIC, which runs over UDP. QUIC combines the transport and encryption handshakes, so a new connection typically needs fewer round trips, and resumed connections can send data even sooner. QUIC also avoids TCP's head-of-line blocking, where one lost packet stalls every stream on the connection. See HTTP/1.1 to HTTP/3 and TCP vs UDP for more.

Browsers also reuse connections aggressively. If you visited the site recently, there may already be an open connection, and much of this step is skipped.

Step 4: The TLS handshake secures the connection

For HTTPS, the client and server run a TLS handshake. In TLS 1.3, the flow is roughly:

• The client sends supported cipher suites and a key share.
• The server replies with its chosen parameters, its key share, and its certificate.
• The browser validates the certificate chain against trusted root authorities and checks that the certificate matches the hostname.
• Both sides derive shared session keys, and encrypted application data begins.

The client also sends the hostname via SNI so one IP address can serve certificates for many domains. After this step, everything, including the path and headers, is encrypted.

Step 5: Sending the HTTP request

Now the browser sends the actual request:

GET /products?page=2 HTTP/2
Host: shop.example.com
Accept: text/html
Accept-Encoding: gzip, br
Cookie: session=abc123
User-Agent: Mozilla/5.0

Cookies for the domain are attached automatically, and caching headers like If-None-Match may be added if the browser already has an older copy.

Step 6: CDN, load balancer, and application server

The request rarely goes straight to one machine.

• A CDN edge may answer immediately from cache for static assets or cacheable pages. See the CDN guide.
• On a cache miss, the request goes to the origin, often through a reverse proxy or load balancer that terminates TLS and picks a healthy backend.
• The application server runs your code: it checks authentication, reads from caches and databases, and builds a response.

The server returns a status code (such as 200, 301, or 404), headers like Content-Type and Cache-Control, and a compressed body.

Step 7: The browser renders the page

Receiving HTML is only the beginning. The browser:

1. Parses HTML into the DOM, streaming as bytes arrive.
2. Discovers CSS, JavaScript, images, and fonts, and fetches them, often in parallel over the same connection.
3. Parses CSS into the CSSOM.
4. Combines DOM and CSSOM into a render tree, computes layout, then paints and composites layers to the screen.

Synchronous scripts block parsing, which is why defer, async, and module scripts matter. Once JavaScript runs, it may fetch more data and update the DOM, triggering further layout and paint.

Summary of each stage

Key takeaways

• DNS turns a hostname into an IP address using layered caches and a hierarchy of name servers.
• TCP needs a handshake before data flows, while QUIC merges transport and encryption setup to save round trips.
• TLS verifies the server's identity with certificates and encrypts everything after the handshake.
• CDNs and reverse proxies often answer or route the request before your application code runs.
• Rendering is its own pipeline: DOM, CSSOM, layout, paint, and composite.

Frequently asked questions

How long does it take to load a URL?

It depends on network distance, cache state, and page weight. A repeat visit with cached DNS, a reused connection, and a CDN hit can feel near-instant, while a cold visit to a distant origin pays for every handshake. Tools like browser dev tools and curl timings show where the time goes.

What is the role of DNS when you type a URL?

DNS translates the human-readable domain name into the IP address of a server. Without it, the browser would not know where to send packets. Caching at the browser, OS, and resolver keeps most lookups fast.

Is TLS the same as HTTPS?

Not exactly. HTTPS is HTTP sent over a TLS-encrypted connection. TLS is the security protocol, and HTTPS is the combination of that protocol with HTTP.

Why is this a common interview question?

It tests breadth across networking, security, backend infrastructure, and browser internals in one answer. Interviewers often let you go deep on whichever layer you know best, so it is worth practicing a clear end-to-end walkthrough.