What Happens When You Type a URL in Your Browser?

Follow one request from the address bar to the screen: DNS, TCP, TLS, HTTP, and rendering, explained step by step.

You press Enter on a website’s address. What happens in the next 200 milliseconds before the page appears?

The honest answer is: a lot. Your browser checks its own memory, looks up a name, opens a connection, secures it, asks for a page, and then turns the reply into pixels. If you have ever wondered what happens when you type a URL in your browser, this guide follows one request from start to finish, in the order things actually happen.

We will use one running example: opening a shopping site during a sale.

Key Takeaways

• A URL is an address for a resource, and the browser works through a fixed chain of steps to fetch it
• DNS turns a name into an IP address, TCP opens a reliable connection, and TLS secures it
• The server side often involves a CDN, a load balancer, an application server, and a database
• The browser then parses HTML and CSS, builds a render tree, lays it out, and paints it
• Knowing the chain makes debugging and performance work much more systematic

1. Why This Question Matters

Why: Most developers use the web every day without seeing its mechanics. Yet this question is a classic interview favorite because the answer touches almost everything: frontend, backend, networking, and DevOps all meet in this one journey.

What: It is a map of the web stack. Each stage you will read about (name lookup, connection, security, request, response, rendering) is owned by a different part of the system, and a problem in any one of them can make a site feel slow or broken.

How: Think of it as a relay race. The browser hands the baton to DNS, then to the network, then to the server, and finally gets it back to draw the page. When something goes wrong, the useful question is not “why is the site broken?” but “which leg of the relay failed?”

That framing helps in practice. A DNS error, a timeout, a certificate warning, and a slow render all look like “the page did not load” to a user, but each points to a different place to investigate.

Here is the order this article follows: names, addresses, connection, security, request, response, and rendering. We finish with a reusable recap checklist and a tour of the browser’s Network tab.

Tradeoff: Going deep on every layer can bury you in detail. You do not need to memorize protocol internals. The goal is a mental model you can reason with, not a specification you can recite.

2. The Big Picture: Life of a Request

Why: Before zooming into DNS or TLS, you need the overall shape of the journey, otherwise each piece feels disconnected.

What: The web follows the client-server model. Your browser is the client; a machine somewhere else is the server. A URL is the address of a resource on that server. The high-level stages are: URL, DNS, connection, request, response, rendering.

How: The work is split across three places. The browser handles URL parsing, cache checks, and rendering. The network carries data between machines. The server builds and sends the response.

It also helps to think in layers. The application layer is where HTTP lives. The transport layer is where TCP (or QUIC) lives. The network layer is where IP addressing and routing live. Each layer does one job and relies on the one below it.

As for time cost, stages that need a round trip over the network (DNS lookup, connection setup, the request itself) usually cost more than local work like checking a cache. Exact numbers vary by network and distance, so treat any single figure with caution.

An analogy: the web is like a postal system. DNS is the address book, routing is the sorting offices, and the server is the house. The analogy breaks down because mail is one-way and slow, while a web request is a fast conversation with many back-and-forth steps.

Tradeoff: A neat staged model hides the fact that real browsers overlap stages. For example, a browser can start fetching resources before it has finished parsing the page.

3. Anatomy of a URL and Browser Pre-Checks

Why: The browser does real work before it touches the network, and understanding it explains why repeat visits feel faster.

What: A URL has up to six parts: scheme (https), host (shop.example.com), port (optional), path (/sale), query (?page=2), and fragment (#reviews). The fragment is used by the browser only and is not sent to the server.

How: First, the address bar decides whether you typed a URL or a search query. If it looks like a search, it goes to your search engine instead.

Next, defaults fill in the blanks. If no port is given, HTTP uses port 80 and HTTPS uses port 443.

Then comes HSTS (HTTP Strict Transport Security). If the site has told the browser to use HTTPS only, the browser upgrades http:// to https:// itself, before sending anything.

Finally, the browser checks its cache, and a service worker (if the site registered one) can intercept the request and answer it locally. On a repeat visit, a cached copy may mean no network call at all.

Tradeoff: Caching speeds things up but can serve stale content, which is why sites set cache rules carefully. This is the cold-versus-warm difference: a first visit pays for every step, while a repeat visit may skip many of them.

4. Finding the Server: DNS Resolution

Why: Humans remember names like shop.example.com. Machines route traffic using IP addresses. Something has to translate between the two.

What: DNS is the internet’s phonebook. It maps a domain name to the IP address (or addresses) where the site lives.

How: The browser looks for an answer in layers of cache first: the browser’s own cache, then the operating system, then the router, then your ISP’s resolver. Any layer that already knows the answer replies immediately.

If nobody knows, a recursive resolver does the legwork. It asks a root server where to find the top-level domain, asks the TLD server (for example .com) where the domain's name servers are, and finally asks the authoritative server, which holds the real answer.

Common record types: an A record maps a name to an IPv4 address, an AAAA record maps to an IPv6 address, and a CNAME record points one name at another name. Each record carries a TTL (time to live), which says how long it may be cached. “DNS propagation” is mostly caches expiring at different times after a change.

Optional snippet to see it yourself:

dig example.com

This asks a resolver for the records of example.com and prints the answer.

Tradeoff: Caching makes DNS fast but means changes are not instant. A long TTL reduces lookups but slows how quickly a change reaches everyone. The phonebook analogy breaks down because DNS is distributed and cached everywhere, not one central book.

5. Reaching the Server: IP, Routing, and TCP

Why: Knowing an IP address is not enough. Data must travel across many networks, and it must arrive complete and in order.

What: IP handles addressing and routing: packets hop from router to router across ISPs until they reach the destination. Ports identify which service on a machine should receive the data, and a socket is the combination of an IP address and a port. TCP sits on top and adds reliability.

How: Before sending the request, the browser opens a TCP connection using the three-way handshake:

The client says “can we talk?” (SYN), the server says “yes, can you hear me?” (SYN-ACK), and the client confirms (ACK).

Once connected, TCP provides reliability: it numbers data so it can be put back in order, resends data that was lost, and uses flow control so a fast sender does not overwhelm a slow receiver.

Every round trip costs latency, measured as round-trip time (RTT). Because the handshake needs a round trip before any data flows, distance to the server directly affects how quickly a page starts. This is one reason CDNs, covered later, place servers closer to users.

Optional snippet:

traceroute example.com

This shows the hops your packets take toward the destination.

Tradeoff: TCP’s guarantees cost time. The handshake and retransmissions add delay, which is acceptable for web pages but is why some real-time apps prefer other transports.

6. Securing the Connection: HTTPS, TLS, and Certificates

Why: Plain HTTP sends data in readable form. Anyone on the path (a shared Wi-Fi network, for example) could read or alter it. For a shopping site, that could mean exposed passwords or card details.

What: HTTPS is HTTP over TLS, which encrypts the connection and lets the browser verify the server’s identity. As Cloudflare’s explanation describes it, a TLS handshake happens after the TCP connection is opened, and it is where client and server agree on a cipher suite and exchange what they need to create session keys.

How: At a high level, the handshake does three jobs: negotiation (agree on the TLS version and cipher suite), authentication (the server presents a certificate), and key exchange (both sides arrive at shared session keys).

The certificate is checked against a chain of trust: your browser trusts certain certificate authorities (CAs), a CA signs the site’s certificate, and so the browser can confirm the certificate is genuine.

Conceptually, asymmetric encryption (a key pair) is used to prove identity and agree on a secret, and symmetric encryption (one shared key) then protects the actual data because it is faster.

The padlock guarantees that the connection is encrypted and that the server proved it controls that domain. It does not guarantee the site is trustworthy or safe.

TLS 1.3 shortens the handshake compared with older versions, according to Cloudflare’s overview. [verify exact round-trip counts before quoting them]

Tradeoff: Security costs extra round trips and CPU work, which newer TLS versions reduce but do not eliminate.

7. The HTTP Request and Server-Side Journey

Why: The secure connection is ready. Now the browser must actually ask for the page, and the server must work out the answer.

What: An HTTP request has a method, a path, headers, optional cookies, and optionally a body. Common methods: GET (read), POST (create), PUT (update), DELETE (remove). The response has a status code, headers, and a body.

How: The request rarely reaches a single machine directly. A CDN or edge server may answer immediately with a cached copy. If not, a load balancer or reverse proxy picks a healthy backend. That web server passes the request to an application server, which may query a database, and the reply travels back the same way.

Status codes tell the browser what happened: 200 means success, 404 means not found, and 500 means a server error. Headers carry details like content type and caching rules, and the body holds the HTML, JSON, or other data.

During a sale, this is where the load balancer and CDN matter most: they spread traffic and serve cached pages so the application server is not overwhelmed.

Optional snippet:

curl -I https://example.com

This fetches only the response headers so you can see the status code and caching hints.

Tradeoff: Each extra layer (CDN, proxy, load balancer) improves scale and resilience but adds another place where things can fail or cache the wrong thing.

8. From Bytes to Pixels: Browser Rendering Pipeline

Why: A response full of text is not a page yet. The browser must turn it into something you can see.

What: Following web.dev’s description of the critical rendering path, the browser builds the DOM from HTML and the CSSOM from CSS, combines them into a render tree, then performs layout (working out sizes and positions) and paint (drawing pixels), with compositing assembling the layers.

How: As the HTML arrives, the parser builds the DOM and discovers more resources to fetch: stylesheets, scripts, images, fonts, and API calls. CSS is render-blocking, because the browser needs styles before it can draw correctly. Scripts can block HTML parsing unless they are marked to load differently.

Reflow vs repaint: a reflow (layout again) happens when a change affects size or position, which is costly. A repaint happens when only appearance changes, such as a color, which is usually cheaper.

The page also fires load events as it progresses, so scripts can run when the DOM is ready or when everything has finished loading.

Tradeoff: More CSS, JavaScript, and images mean richer pages but more waiting. Deferring non-critical resources speeds up the first paint at the cost of extra planning.

9. HTTP/1.1 vs HTTP/2 vs HTTP/3

Why: A modern page needs dozens of resources. How the protocol carries them changes how fast the page feels.

What: Three generations of HTTP exist, each tackling a limit of the last. Comparing them is about tradeoffs, not picking a winner.

How: HTTP/1.1 handles one request at a time per connection, so browsers open several connections in parallel. A slow response can hold up the ones behind it, known as head-of-line blocking.

HTTP/2 allows multiplexing: many requests and responses share one connection at the same time. It also compresses headers to cut repeated overhead.

HTTP/3 runs over QUIC, which is built on UDP rather than TCP. The aim is to avoid TCP-level head-of-line blocking and speed up connection setup.

TCP vs QUIC: TCP is mature and universally supported. QUIC offers different performance behavior, particularly on lossy networks, but depends on UDP being allowed through networks and on server and client support. [verify performance claims for your own use case]

Caching: a browser cache stores files on the user’s device, while a CDN cache stores them on edge servers near many users. Both cut repeat work, at different layers.

Cookies, sessions, tokens (briefly): cookies are small data stored by the browser and sent with requests. A session keeps state on the server, while a token carries it in a signed value the client sends back.

Tradeoff: Newer is not automatically better for every site. Adoption depends on browser, server, and network support, so most sites fall back gracefully to older versions.

10. Debugging, Performance, and Applying the Knowledge

Why: This knowledge pays off when something is slow or broken, and in interviews and system design.

What: The browser’s developer tools show the journey in real time, with a timing breakdown for each request.

How: Try it yourself: open DevTools, go to the Network tab, reload a page, and click any request. Look at its timing breakdown. You will typically see time spent on things like DNS lookup, connecting, TLS, waiting for the first byte, and downloading the content. Compare a first visit against a repeat visit to see caching at work.

Common failures map to stages: DNS errors point to name lookup, timeouts to connection or server, SSL errors to certificates, 404 to a missing resource, and 500 to a server-side bug.

Quick wins: cache static files, use a CDN, compress responses, and reduce the number of requests.

Where to optimize: if the delay is before the first byte, look at network and server; if it is after, look at the browser (large scripts, render-blocking CSS, layout work).

Recap checklist for interviews:

• URL parsed, pre-checks run (HSTS, cache, service worker)
• DNS resolves the name to an IP address
• TCP connection opens with a three-way handshake
• TLS secures the connection and verifies the certificate
• HTTP request is sent, possibly via CDN and load balancer
• Application server and database build the response
• Browser builds DOM and CSSOM, then layout, paint, and composite
• Sub-resources load, and the page finishes

Next learning steps: networking basics, system design, and web performance.

Tradeoff: Speed, security, and simplicity pull in different directions. Every extra optimization or security layer adds complexity, so measure first and fix what the data points to.

FAQ

What happens first when you type a URL?

> The browser decides if it is a URL or a search, applies defaults and HSTS, and checks its cache before using the network.

Why does DNS come before everything else?

> Because the browser needs an IP address to know which machine to connect to.

Is HTTPS slower than HTTP?

> It adds a handshake, but newer TLS versions reduce that cost, and HTTPS is the standard for security reasons.

What is the difference between DOM and CSSOM?

> The DOM represents page structure from HTML, and the CSSOM represents styles from CSS. They combine into the render tree.

Does HTTP/3 replace HTTP/2?

> Not entirely. Both are in use, and the best choice depends on support and the network conditions.

What Happens When You Type a URL in Your Browser? was originally published in Towards Dev on Medium, where people are continuing the conversation by highlighting and responding to this story.