Have you ever wondered what happens after you type a URL into your browser and press Enter?
For example:
https://example.com
A webpage appears within a few seconds, but a lot happens behind the scenes before you see it.
In a simplified form, the process looks like this:
URL
↓
DNS Lookup
↓
TCP Connection
↓
TLS Handshake
↓
HTTP Request
↓
Web Server
↓
HTTP Response
↓
Browser Processes Response
↓
Page Rendered
Let's understand each step in simple terms.
1. The Browser Reads the URL
First, the browser breaks the URL into different parts.
Consider:
https://example.com/products?id=10
It contains:
https:// → Protocol
example.com → Domain
/products → Path
?id=10 → Query parameter
The protocol tells the browser how it should communicate with the server.
For HTTPS, the default port is:
443
For HTTP, the default port is:
80
So when you type:
https://example.com
the browser knows that it needs to communicate securely with the server using HTTPS.
2. DNS Finds the Server
Computers communicate using IP addresses.
Humans, however, prefer names like:
example.com
instead of:
93.184.216.34
This is where DNS (Domain Name System) comes in.
DNS translates a domain name into an IP address.
A simplified flow looks like:
example.com
↓
DNS
↓
IP Address
You can actually perform a DNS lookup from your terminal.
Windows
nslookup example.com
Linux / macOS
dig example.com
The result contains information about the domain's DNS records, including its IP address.
The browser can then use that IP address to communicate with the destination server.
3. DNS Isn't Always Requested From Scratch
One important detail is that the browser doesn't necessarily perform a complete DNS lookup every time.
DNS information can be cached at different levels:
Browser Cache
↓
Operating System Cache
↓
DNS Resolver Cache
↓
DNS Servers
If a valid cached result already exists, the browser may use it instead of performing another lookup.
This caching helps reduce latency and unnecessary DNS traffic.
4. A Connection Is Established
Once the browser knows the server's IP address, it needs to establish a connection.
For traditional HTTPS over TCP, this starts with the TCP three-way handshake.
It looks like this:
Client Server
SYN ------------------------>
<------------------------ SYN + ACK
ACK ------------------------>
Step 1: SYN
The client sends a SYN packet to start a connection.
Step 2: SYN-ACK
The server responds with SYN-ACK.
Step 3: ACK
The client sends an ACK.
The TCP connection is now established.
Modern HTTP/3 uses QUIC over UDP instead of TCP, so not every HTTPS connection follows this exact TCP flow.
5. HTTPS Establishes Secure Communication
Because we're using:
https://
the connection needs encryption.
This is handled by TLS (Transport Layer Security).
The browser and server perform a TLS handshake to establish secure communication.
A simplified version looks like:
Browser Server
ClientHello ------------------>
<------------------ ServerHello
<------------------ Certificate
Certificate verification
Key exchange ------------------>
Encrypted communication begins
The browser verifies the server's certificate and establishes cryptographic keys for the connection.
After this point, the HTTP data can be exchanged securely.
This is one of the main differences between:
HTTP
and:
HTTPS
HTTPS protects the communication between the client and server using TLS.
6. The Browser Sends an HTTP Request
Now the browser can send the actual request.
For example:
GET /products HTTP/1.1
Host: example.com
Accept: text/html
The request tells the server what the browser wants.
An HTTP request generally contains:
Request Method
URL / Path
Headers
Optional Body
Common HTTP methods include:
GET → Read data
POST → Create data
PUT → Replace/update data
PATCH → Partially update data
DELETE → Delete data
For example:
GET /products
means:
Give me the products resource.
7. The Request Reaches the Server
The request doesn't necessarily go directly from the browser to your application.
A production application can have several layers:
Browser
↓
Internet
↓
CDN / Load Balancer
↓
Web Server / Reverse Proxy
↓
Backend Application
↓
Database
For a simple MERN application, you might have:
React
↓
Node.js + Express
↓
MongoDB
The backend receives the request and decides what should happen next.
8. Express Handles the Request
Suppose our frontend sends:
GET /api/products
An Express server could handle it like this:
const express = require("express");
const app = express();
app.get("/api/products", (req, res) => {
const products = [
{
id: 1,
name: "Laptop",
price: 60000
},
{
id: 2,
name: "Keyboard",
price: 2000
}
];
res.json(products);
});
app.listen(3000, () => {
console.log("Server running on port 3000");
});
When the browser sends:
GET /api/products
Express matches the route:
app.get("/api/products", ...)
and executes the function.
The server then sends the products back as JSON.
9. The Backend May Talk to a Database
In a real application, we usually don't hardcode the data.
The backend may query a database.
For example, using Mongoose:
app.get("/api/products", async (req, res) => {
try {
const products = await Product.find();
res.json(products);
} catch (error) {
res.status(500).json({
message: "Something went wrong"
});
}
});
Now the flow becomes:
Browser
↓
HTTP Request
↓
Express
↓
Route
↓
MongoDB
↓
Data
↓
Express
↓
HTTP Response
This is the basic request-response cycle you'll use frequently as a MERN developer.
10. The Server Sends an HTTP Response
After processing the request, the server sends a response.
For example:
HTTP/1.1 200 OK
Content-Type: application/json
The response body could be:
[
{
"id": 1,
"name": "Laptop",
"price": 60000
},
{
"id": 2,
"name": "Keyboard",
"price": 2000
}
]
The status code tells the client what happened.
Some commonly used status codes are:
| Status Code | Meaning |
|---|---|
| 200 | Request successful |
| 201 | Resource created |
| 400 | Bad request |
| 401 | Authentication required |
| 403 | Access forbidden |
| 404 | Resource not found |
| 500 | Server error |
For example:
res.status(404).json({
message: "Product not found"
});
sends a 404 Not Found response.
11. The Browser Processes the Response
If the browser requested an HTML document, it starts parsing the HTML.
For example:
<!DOCTYPE html>
<html>
<head>
<title>My Website</title>
</head>
<body>
<h1>Hello World</h1>
<p>Welcome to my website.</p>
</body>
</html>
The browser parses this HTML and creates a DOM (Document Object Model).
Conceptually:
HTML
↓
DOM
The DOM represents the structure of the webpage.
For example:
Document
|
html
|
body
/ \
h1 p
JavaScript can then interact with this DOM.
12. The Browser Loads CSS
The HTML might contain:
<link rel="stylesheet" href="/style.css">
The browser makes another request for:
/style.css
The server might return:
body {
font-family: Arial, sans-serif;
}
h1 {
font-size: 32px;
}
p {
line-height: 1.6;
}
The browser uses this CSS to determine how the HTML elements should look.
13. JavaScript Is Downloaded and Executed
The webpage can also contain JavaScript.
For example:
<script src="/app.js"></script>
The browser downloads the JavaScript file and executes it.
For example:
const button = document.querySelector("#button");
button.addEventListener("click", () => {
console.log("Button clicked");
});
JavaScript can:
- Modify the DOM
- Handle user interactions
- Send API requests
- Update application state
- Perform calculations
- Change the UI
This is where modern frontend frameworks such as React become useful.
14. What Changes in a React Application?
In a React application, the browser loads the application JavaScript and React takes responsibility for building the user interface.
A simplified flow looks like:
Browser
↓
HTML
↓
JavaScript
↓
React
↓
API Request
↓
Express Backend
↓
Database
For example, a React component might request data:
import { useEffect, useState } from "react";
function Products() {
const [products, setProducts] = useState([]);
useEffect(() => {
fetch("/api/products")
.then(response => response.json())
.then(data => setProducts(data));
}, []);
return (
<div>
{products.map(product => (
<p key={product.id}>
{product.name} - ₹{product.price}
</p>
))}
</div>
);
}
export default Products;
Here, another HTTP request is made from the browser to:
/api/products
The backend returns JSON, and React uses that data to update the UI.
15. The Browser Renders the Page
Once the browser has the required HTML and CSS, it needs to turn them into pixels on your screen.
A simplified rendering process is:
HTML
↓
DOM
↓
CSS
↓
CSSOM
↓
Render Tree
↓
Layout
↓
Paint
↓
Composite
↓
Screen
Layout
The browser calculates where elements should appear and how much space they need.
Paint
It draws things such as:
- Text
- Colors
- Borders
- Images
- Shadows
Composite
The browser combines the different visual layers and displays the final result.
16. One URL Can Trigger Many Requests
This is an important thing to understand.
You may type only:
https://example.com
but loading that page may require many requests:
index.html
↓
style.css
↓
app.js
↓
images
↓
fonts
↓
API requests
For a modern web application, the browser may continue making requests even after the initial HTML has loaded.
You can see these requests yourself.
Open Browser DevTools
In Chrome or another Chromium-based browser:
Right Click
↓
Inspect
↓
Network
Then reload the page.
You'll see requests for things such as:
HTML
CSS
JavaScript
Images
Fonts
API calls
This is one of the best ways to understand what your browser is actually doing.
17. You Can See the Process Yourself
Open DevTools and go to the Network tab.
When you reload a website, you'll see information such as:
Name
Status
Type
Size
Time
For an API request, you may see:
GET /api/products
Status: 200
Type: fetch
You can click the request and inspect:
Headers
Payload
Preview
Response
Timing
This is extremely useful when debugging frontend and backend applications.
18. What If Something Goes Wrong?
Understanding the request flow makes debugging easier.
DNS problem
The domain cannot be resolved.
Domain
↓
DNS
X
IP address not resolved
404 Error
The server was reached, but the requested resource doesn't exist.
GET /products/100
↓
404
500 Error
The request reached the backend, but the server encountered an error while processing it.
Network Error
The browser may not be able to communicate with the server because of a network, connection, server, or configuration issue.
CORS Error
The browser can block a cross-origin request when the server does not allow that origin through its CORS configuration.
For example:
Frontend
http://localhost:5173
↓
Backend
http://localhost:5000
These are different origins, so the backend may need appropriate CORS configuration.
The Complete Flow
Now let's put everything together.
When you enter:
https://example.com
a simplified version of what happens is:
URL
↓
Browser parses URL
↓
DNS lookup
↓
IP address
↓
Connection established
↓
TLS handshake
↓
HTTP request sent
↓
Web server
↓
Backend application
↓
Database / Services
↓
HTTP response
↓
Browser receives it
↓
HTML / CSS / JS
↓
Browser rendering
↓
Web page
And that's the journey from typing a URL to seeing a webpage.
Why Should a Web Developer Understand This?
You don't need to become a networking expert to build websites.
But understanding this flow gives you a much better mental model of web development.
When an API isn't working, you can ask:
Did the request leave the browser?
↓
Did DNS resolve correctly?
↓
Did the server receive the request?
↓
Did the Express route match?
↓
Did the database query work?
↓
What status code did the server return?
↓
Did the browser receive the response?
Instead of randomly changing code, you can debug the problem step by step.
That's the real value of understanding what happens behind a URL.
Final Takeaway
Typing a URL looks like one simple action, but it starts a chain of operations involving:
- DNS
- Networking
- TCP or QUIC
- TLS
- HTTP
- Web servers
- Backend applications
- Databases
- HTML
- CSS
- JavaScript
- Browser rendering
As a developer, you don't need to memorize every detail.
The important thing is to understand how these pieces connect.
Once you have that mental model, concepts like APIs, authentication, React, Node.js, Express, databases, and browser DevTools become much easier to understand.
And the next time you press Enter after typing a URL, you'll know there's a lot more happening than just "opening a website."
Top comments (0)