07 SEPT 2025 · 7 MIN READ

What Happens When You Hit a URL in Your Browser

#networking

Let me walk you through exactly what's happening when you type https://www.google.com/api/search?q=home and hit enter. This is the kind of stuff that, once you understand it, makes you appreciate how much heavy lifting the internet does for us every single day.

what you'll take away

quick pointers so you know what to look for as you read:

a url is a contract. scheme, domain, path, query — each piece is consumed by a different layer of the journey.
the steps have a strict order for a reason. no ip, no tcp connection; no connection, no http.
http is just text over the connection. verb, path, headers in; status, headers, body out.
content-type decides what the browser does next. render it, execute it, or download it.
one page load is many round trips. every css file, image, and script repeats the whole dance.

Understanding URLs: The Address System of the Internet

Before we dive into the process, let's break down what constitutes a URL. A URL is basically a human-readable way to know what we are interested in - it's our map to navigate the web.

Looking at https://www.google.com/api/search?q=home, here's what each piece means:

https - This is the scheme. It tells the browser which protocol to use while connecting to the server. Other schemes include http, ws (WebSocket), wss (WebSocket Secure), etc.
www.google.com - This is the domain we want to connect to. It's the human-readable address of the server.
/api/search - This is the path. It tells the server which specific resource we're interested in accessing.
?q=home - These are query parameters - optional key-value pairs we can pass to provide additional information in the request.

The beauty of this system is that it gives us a human-readable way to specify exactly where we want to go and what we want to do. But here's the thing - machines don't actually understand domain names. They need IP addresses.

✽ RECALL in https://www.google.com/api/search?q=home, which part is consumed by the browser, which by the network, and which by the server?

the scheme (https) tells the browser which protocol to speak; the domain is what gets resolved to an ip so the network can route you; the path and query parameters travel inside the request for the server to interpret. each layer reads its piece and ignores the rest — that's what makes the url a contract.

The DNS Resolution: Converting Names to Numbers

Why do we need DNS resolution? Every machine on the internet has an "address" enabling us to reach it over the network - this is the IP address. But it's much easier to remember "google.com" than "17.53.21.253", right?

Hence, we need a way that converts google.com → 17.53.21.253. This process is called DNS resolution.

Here's what actually happens during DNS resolution:

The browser does a DNS lookup to get the associated IP address. What looks like a simple call actually involves lots of machines working together in an iterative process. Your request might go through:

Local browser cache - DNS information is heavily cached in the browser
Operating system cache - The OS caches this across all machines
Root DNS servers - The authoritative source for all DNS information
TLD servers - Top-level domain servers (for .com, .org, .in, etc.)
Authoritative name servers - The final authority for specific domains

[Reference to other DOC DNS]

Key insight: DNS information is heavily cached at every layer - in the browser, in the operating system, across all machines involved in DNS resolution. This is why subsequent requests are served much faster.

After this resolution process, the browser has the IP address to connect to.

✽ RECALL why must dns resolution happen before anything else in the page-load sequence?

because every later step hangs off the ip address — you can't open a tcp connection to a name, and you can't send http without a connection. that hard ordering is why dns gets cached so aggressively at every layer (browser, os, resolver): it's the gate everything else waits behind.

Establishing the Connection: TCP Handshake

Once the browser has the IP address (17.53.21.253 in our case), it can now establish a connection. Since we're using HTTPS, the browser now establishes a TCP connection with the machine (server) and can now talk to it over the network.

But here's where it gets interesting - this isn't just connecting to a single server. This is actually connecting to a huge infrastructure that might include:

Load balancers
API gateways
Multiple servers
Service meshes

This in itself is a Pandora's Box and consists of 1000s of machines. [I will write more about this later]

For now, the core idea is: your browser can now establish a connection with this machine, and internally it might go to some other machines across multiple layers.

Sending the Request: HTTP in Action

Now that the TCP connection is established, the browser now compiles the request into HTTP specification and sends it across to the server.

Since we're just hitting a URL in the browser, it defaults to an HTTP GET request. The browser creates an HTTP message that looks like this:

 
GET /api/search?q=home HTTP/1.1
Host: www.google.com
Connection: keep-alive

Let me break this down:

GET - The HTTP verb (other protocols are possible)
/api/search?q=home - The path and query parameters
HTTP/1.1 - The HTTP protocol version
Headers - Additional metadata and instructions to the server

HTTP is a protocol that specifies:

How to pack the data
What to do before, during, and after the request

[Write another blog here for HTTP and Protocols]

Given we are just hitting a URL in the browser, it fires an HTTP GET to the server.

✽ RECALL what actually goes over the wire when the browser "sends a request" — and why does typing a url always produce a GET?

a plain-text http message: a verb, the path plus query params, the protocol version, then headers like Host and Connection. hitting a url in the address bar is a read with no body to send, so the browser defaults to GET. http itself is just the agreed format for packing this data and the rules around the exchange.

Server Processing: The Business Logic

Once the server receives the HTTP request, it parses the above message and understands what needs to be done.

The server may:

Load a file from local disk and serve it
Make a call to database to get response
Throw an error if malformed

It compiles a proper HTTP response and responds back over the same TCP connection.

A typical HTTP response looks like:

 
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 2042

<html><head>....... ~ body

Let me explain each part:

200 - Status code (everything went OK)
Content-Type: text/html - Type of content being returned
Content-Length: 2042 - Length of the response body
<html><head>...... - The actual HTML body

Browser Rendering: Bringing It All Together

Browser upon receiving the response parses the message, extracts the info, and "renders" it.

The browser looks at the response and sees:

Status code - Was the request successful?
Content-Type - How should I handle this content?
Body - What should I actually display?

Since the content type is text/html, the browser knows to render this as an HTML page. If the browser does not support the response type, then it downloads the file locally instead of trying to render it.

But here's where it gets really interesting - when HTML is rendered, the browser may come across:

Linked CSS files - It fetches the additional files by going through the same process
IMG tags to render an image - Same HTTP flow for each image
Inline JavaScript code - It starts executing it, which may involve making more HTTP requests

For each of these additional resources, the browser repeats this entire process - DNS lookup (if needed), TCP connection, HTTP request, response processing, and rendering.

✽ RECALL the server sends back bytes — how does the browser decide whether to render, execute, or download them?

it reads the response metadata first: the status code says whether things went ok, and Content-Type says what the body is. text/html gets rendered, scripts get executed, and anything the browser doesn't know how to handle gets downloaded as a file instead of being displayed.

✽ RECALL why is loading "one page" actually dozens of request cycles?

rendering the html surfaces more work — linked css, img tags, scripts that fire their own requests. each one repeats the full journey: dns (if not cached), tcp connection, http request, response, render. the page you see is the sum of many small round trips, not one big one.

The Complete Picture

What looks like a simple call actually involves lots of machines working together. This is a very 10,000-foot view of what happens when you hit a URL in your browser.

✽ ❦ ✽