What Happens When You Type a URL and Press Enter

It's one of the most common interview questions for web developers, and for good reason. If you understand what happens between pressing Enter and seeing a page, you understand where almost every web performance problem, security issue and "why doesn't this load?" bug comes from.

Let's follow a request for https://example.com/blog from start to finish.

1. The browser figures out what you typed

First, the browser decides whether you typed a URL or a search query. example.com/blog looks like a URL, so it fills in the scheme (https://) and gets ready to fetch it.

It also checks its own caches. If you visited recently and the page was cached with the right headers, it might not need the network at all.

2. DNS: turning a name into an address

Computers talk to IP addresses, not names. So the browser needs the IP address for example.com. It asks, in order:

1. Its own DNS cache
2. The operating system's cache (and the hosts file)
3. A DNS resolver, usually run by your ISP, your router or a public service

If the resolver doesn't know the answer, it walks the DNS hierarchy: the root servers point to the .com servers, which point to the domain's own nameservers, which finally answer with an IP address. The answer gets cached at each step for the record's TTL (time to live).

This is why DNS changes "take time to propagate". Nothing is really propagating. Caches around the world are just waiting for old answers to expire. (DNS explained in more depth.)

3. Opening a connection: TCP and TLS

With the IP address in hand, the browser opens a connection to the server.

• TCP handshake: a quick back-and-forth that establishes a reliable connection. Newer HTTP/3 uses QUIC over UDP instead, which combines connection setup with encryption to save round trips.
• TLS handshake: because it's https, the browser and server agree on encryption keys, and the server proves its identity with a certificate signed by a trusted authority. (How HTTPS works.)

Each round trip costs time, especially on mobile networks or when the server is far away. That's one reason CDNs, which put servers close to users, make such a big difference.

4. The HTTP request

Now the browser sends the actual request:

GET /blog HTTP/2
Host: example.com
Accept: text/html
Accept-Language: en-GB
Cookie: session=abc123

The method (GET), the path (/blog), and headers carrying extra information like cookies, preferred language and what formats the browser accepts.

5. The server does its work

On the other end, a lot can happen:

• A CDN or load balancer might answer directly from cache, or forward the request to one of several servers.
• A web server like Nginx might serve a static file, or pass the request to your application (reverse proxies explained).
• Your application runs routing, middleware, authentication and business logic, and probably queries a database.
• It builds a response: a status code, headers and a body.

HTTP/2 200
Content-Type: text/html; charset=utf-8
Cache-Control: no-cache

The status code tells the browser what happened. (Status codes explained.)

6. The browser renders the page

The HTML arrives, and the browser starts building the page, often before the whole file has even downloaded:

1. Parse HTML into the DOM (a tree of elements).
2. Discover resources: stylesheets, scripts, images and fonts, which trigger more requests.
3. Parse CSS into the CSSOM.
4. Run JavaScript. Scripts without defer or async block parsing while they download and execute.
5. Layout: calculate the size and position of every element.
6. Paint and composite: draw pixels to the screen.

If JavaScript later changes the DOM or styles, parts of this pipeline run again. Do that carelessly in a loop and you get janky scrolling.

7. Everything after the first load

The page is visible, but the story continues: images lazy-load, analytics fire, a framework hydrates the page to make it interactive, and API calls fetch more data. Each of those is another trip through the same steps, minus whatever is cached.

Why this matters day to day

Once you see the whole chain, a lot of advice suddenly makes sense:

• Slow first byte? Look at the server and database (step 5).
• Slow everything else? Look at render-blocking resources and images (step 6). (Diagnosing a slow site.)
• Site works for you but not others? DNS caching (step 2) is a common culprit after domain changes.
• "Mixed content" warnings? Something on an HTTPS page is loading over plain HTTP (step 3).
• CORS errors? That's the browser enforcing rules on responses from other origins. (Fixing CORS.)

FAQ

What happens when you type a URL in the browser?

The browser resolves the domain to an IP address with DNS, opens a TCP (or QUIC) connection, negotiates TLS encryption, sends an HTTP request, receives the server's response and then parses and renders the HTML, CSS and JavaScript.

Why is the first visit to a website slower?

Nothing is cached yet: DNS answers, connections and static files all have to be fetched fresh. On later visits, cached resources and reused connections make loading much faster.

What is the difference between HTTP/1.1, HTTP/2 and HTTP/3?

HTTP/2 sends many requests over a single connection at once. HTTP/3 does the same over QUIC, a UDP-based transport that sets up connections faster and handles packet loss better, especially on mobile networks.