HTTP Request Lifecycle Explained — What Really Happens When You Hit Enter

You type https://google.com into your browser and press Enter.

In about 200 milliseconds, a fully rendered page appears.

But what actually happened in those 200 milliseconds?

Most developers — even experienced ones — have a vague idea. ‘DNS happens, then TCP, then… HTTP stuff.’ But if you’re building backends, designing APIs, debugging slow responses, or preparing for system design interviews, ‘vague’ is not good enough.

In this post, we’re going to trace every single thing that happens — from the moment you press Enter to the moment the response arrives — explained in plain language with real examples and actual HTTP messages.

Let’s go.

The 7 Stages at a Glance
Before we dive deep into each stage, here’s the full picture:

Stage What Happens Who Does It

1. URL Parsing Browser breaks down the URL into parts Browser
2. DNS Lookup Domain name is resolved to an IP address OS + DNS Servers
3. TCP Handshake A reliable connection is established Client + Server
4. TLS Handshake Connection is encrypted (HTTPS only) Client + Server
5. HTTP Request Client sends the actual request message Browser / HTTP Client
6. Server Processing Server receives, routes, processes, and responds Your Backend Code
7. Connection End Connection is closed or kept alive for future requests Client + Server 💡 As a backend developer, you directly control Stage 6 (Server Processing). But understanding Stages 1-5 is what lets you diagnose slow APIs, set correct headers, design better systems, and answer senior-level interview questions. Stage 1 URL Parsing

Before anything goes over the network, the browser breaks down what you typed into structured parts.

Take this URL: https://api.example.com:443/users/42?format=json#profile

Part Value What it means
Scheme https Use HTTPS protocol (encrypted HTTP)
Host api.example.com The domain name to connect to
Port 443 Port number (443 is default for HTTPS, 80 for HTTP)
Path /users/42 The specific resource being requested
Query ?format=json Additional parameters passed to the server
Fragment #profile Client-side anchor — never sent to the server
🔑 The fragment (#profile) is NEVER sent to the server. It is processed entirely by the browser. Your backend will never see it. This is a classic interview gotcha.
The browser also checks a few things at this stage:

Is this a valid URL format?
Is the scheme supported (http, https, ftp, etc.)?
If no port is specified — assume 80 for HTTP, 443 for HTTPS
Encode any special characters in the path or query using percent-encoding (spaces become %20, etc.)
Stage 2 DNS Lookup — Translating Domain to IP Address

Your computer does not know where ‘api.example.com’ is. It only understands IP addresses — numerical addresses like 142.250.80.46. DNS (Domain Name System) is the phonebook that translates one to the other.

The DNS Resolution Chain
DNS lookup does not happen in one step. It’s a chain of queries, each one more specific than the last:

Step Where it checks What it does
1 Browser DNS cache Did I recently look up this domain? Use cached IP.
2 OS DNS cache Has this machine looked it up? Check /etc/hosts and OS cache.
3 Router / ISP DNS Ask the local DNS resolver (usually your router or ISP).
4 Root DNS servers 13 root servers worldwide. Returns address of TLD nameserver.
5 TLD nameserver (.com, .in) Returns address of the domain’s authoritative nameserver.
6 Authoritative nameserver Returns the actual IP address for the domain.

READ FULL POST: https://dailydevnotes.in/slug-http-request-lifecycle-explained-backend/