DEV Community: Aryan Gupta

How HTTP Requests Work?

Aryan Gupta — Fri, 02 Oct 2026 05:08:21 +0000

Have you ever wondered what actually happens when you click a button on a website and data appears on the screen?

For example, you open an e-commerce website and click "View Products".

Behind the scenes, your frontend might send a request like:

GET /api/products

The backend receives this request, processes it, may communicate with a database, and finally sends a response back.

But how does this actually work?

What is inside an HTTP request?

What are headers?

What is the difference between GET, POST, PUT, and DELETE?

What are query parameters and URL parameters?

And how does all of this connect to a MERN application?

Let's understand HTTP requests step by step.

1. What is HTTP?

HTTP stands for HyperText Transfer Protocol.

It is a protocol that allows clients and servers to communicate with each other over a network.

A client can be:

Web browser
React application
Mobile application
API testing tool
Another server

A server can be:

Node.js server
Express server
Java backend
Python backend
Any application that can handle HTTP requests

The basic communication looks like this:

Client
   |
   | HTTP Request
   ↓
Server
   |
   | HTTP Response
   ↓
Client

The client asks for something, and the server responds.

This is called the request-response model.

2. A Simple HTTP Request

Suppose we have an API for getting products.

The client sends:

GET /api/products HTTP/1.1
Host: example.com
Accept: application/json

The server might respond:

HTTP/1.1 200 OK
Content-Type: application/json

[
    {
        "id": 1,
        "name": "Keyboard",
        "price": 2000
    }
]

There are several important parts here.

The request contains:

HTTP Method
URL / Path
Headers
Body

The response contains:

Status Code
Headers
Body

Let's understand each part.

3. Anatomy of an HTTP Request

An HTTP request can contain four important parts:

Method
URL
Headers
Body

For example:

POST /api/products HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer token123

{
    "name": "Keyboard",
    "price": 2000
}

Let's break it down.

Method

POST

This tells the server what operation the client wants to perform.

URL / Path

/api/products

This tells the server which resource the client wants to access.

Headers

Content-Type: application/json
Authorization: Bearer token123

Headers provide additional information about the request.

Body

{
    "name": "Keyboard",
    "price": 2000
}

The body contains the actual data being sent to the server.

4. HTTP Methods

HTTP methods tell the server what the client wants to do.

The most commonly used methods are:

Method	Purpose	Example
GET	Read data	Get products
POST	Create data	Create a product
PUT	Replace/update data	Replace a product
PATCH	Partially update data	Update product price
DELETE	Delete data	Delete a product

Let's understand them one by one.

GET

GET is used to retrieve data.

Example:

GET /api/products

Express:

app.get("/api/products", (req, res) => {
    res.json({
        message: "Products fetched successfully"
    });
});

The server returns the requested data.

POST

POST is generally used to create new data.

Example:

POST /api/products

The client can send product information in the request body:

{
    "name": "Keyboard",
    "price": 2000
}

Express:

app.post("/api/products", (req, res) => {
    res.status(201).json({
        message: "Product created successfully"
    });
});

PUT

PUT is generally used to replace an existing resource.

Example:

PUT /api/products/10

The client may send the complete updated resource.

{
    "name": "Mechanical Keyboard",
    "price": 3500
}

PATCH

PATCH is generally used to partially update a resource.

For example, if we only want to change the price:

PATCH /api/products/10

Body:

{
    "price": 3500
}

We don't need to send the entire product.

DELETE

DELETE is used to delete a resource.

Example:

DELETE /api/products/10

Express:

app.delete("/api/products/:id", (req, res) => {
    res.json({
        message: "Product deleted successfully"
    });
});

5. GET vs POST

One of the most common questions when learning backend development is:

What is the difference between GET and POST?

GET

Used to retrieve data.

GET /api/products

POST

Used to send data to the server, commonly to create a resource.

POST /api/products

For example:

{
    "name": "Keyboard",
    "price": 2000
}

A simple way to remember:

GET  → Give me data

POST → Here is some data

6. What are HTTP Headers?

Headers provide additional information about an HTTP request or response.

For example:

Content-Type: application/json
Authorization: Bearer token123
Accept: application/json

Headers follow this format:

Name: Value

For example:

Content-Type: application/json

means that the content being sent is JSON.

7. Important HTTP Headers

There are many HTTP headers, but some are especially important for web developers.

Content-Type

Tells the server what type of data is being sent.

Content-Type: application/json

For example:

{
    "name": "Keyboard"
}

Accept

Tells the server what type of response the client expects.

Accept: application/json

Authorization

Commonly used for authentication.

Authorization: Bearer token123

We will explore authentication and JWT in later parts of this series.

Cookie

Cookies can be sent from the browser to the server.

Cookie: sessionId=abc123

Cookies are commonly used for sessions, authentication, preferences, and other browser-related data.

Cache-Control

Used to control caching behavior.

Cache-Control: max-age=3600

We will discuss caching in a later part of this series.

8. What is the Request Body?

The request body contains data sent from the client to the server.

For example, when creating a product:

POST /api/products
Content-Type: application/json

{
    "name": "Mechanical Keyboard",
    "price": 3500
}

The JSON object is the request body.

In Express, we can access it using:

req.body

First, we need to enable JSON parsing:

const express = require("express");

const app = express();

app.use(express.json());

app.post("/api/products", (req, res) => {
    console.log(req.body);

    res.json({
        message: "Product received"
    });
});

If the client sends:

{
    "name": "Mechanical Keyboard",
    "price": 3500
}

then:

req.body

contains:

{
    name: "Mechanical Keyboard",
    price: 3500
}

9. Query Parameters

Query parameters are values added to the URL.

For example:

/api/products?category=keyboard

Here:

category=keyboard

is a query parameter.

We can have multiple query parameters:

/api/products?category=keyboard&sort=price

In Express:

app.get("/api/products", (req, res) => {
    console.log(req.query);

    res.json(req.query);
});

For:

/api/products?category=keyboard&sort=price

we get:

{
    category: "keyboard",
    sort: "price"
}

Query parameters are commonly used for:

Searching
Filtering
Sorting
Pagination

For example:

/api/products?search=keyboard

or:

/api/products?page=2&limit=10

10. URL Parameters

URL parameters are values included directly in the URL path.

For example:

/api/products/123

Here:

can represent the product ID.

In Express:

app.get("/api/products/:id", (req, res) => {
    console.log(req.params.id);

    res.json({
        productId: req.params.id
    });
});

If we request:

/api/products/123

then:

req.params.id

will contain:

URL parameters are commonly used when accessing a specific resource.

11. Query Parameters vs URL Parameters vs Request Body

These three concepts are commonly confused when learning backend development.

Query Parameter

/api/products?category=keyboard

Used for:

Filtering
Searching
Sorting
Pagination

Access using:

req.query

URL Parameter

/api/products/123

Used to identify a specific resource.

Access using:

req.params

Request Body

{
    "name": "Keyboard",
    "price": 2000
}

Used to send data to the server.

Access using:

req.body

A simple way to remember:

Query Parameter → Filter or modify the request

URL Parameter   → Identify a resource

Request Body    → Send data

12. HTTP Status Codes

After processing the request, the server sends a response.

One important part of the response is the HTTP status code.

For example:

HTTP/1.1 200 OK

Here:

is the status code.

HTTP status codes are divided into five categories:

1xx → Informational
2xx → Success
3xx → Redirection
4xx → Client Error
5xx → Server Error

You don't need to memorize every status code.

Let's look at the important ones.

13. Common 2xx Status Codes

200 OK

The request was successful.

res.status(200).json({
    message: "Products fetched successfully"
});

201 Created

A new resource was successfully created.

res.status(201).json({
    message: "Product created successfully"
});

This is commonly used after a successful POST request.

204 No Content

The request was successful, but the server does not return a response body.

It can be useful when an operation succeeds but there is nothing to return.

14. Common 4xx Status Codes

These usually indicate a problem with the client's request.

400 Bad Request

The request is invalid.

res.status(400).json({
    message: "Invalid product data"
});

401 Unauthorized

Authentication credentials are missing or invalid.

res.status(401).json({
    message: "Authentication required"
});

403 Forbidden

The server understands the request, but the user does not have permission.

For example:

Normal User
     ↓
Admin-only resource
     ↓
403 Forbidden

404 Not Found

The requested resource does not exist.

For example:

GET /api/products/999

If product 999 doesn't exist:

res.status(404).json({
    message: "Product not found"
});

15. Common Server Error Status Codes

These indicate that something went wrong on the server.

500 Internal Server Error

Something unexpected happened while processing the request.

res.status(500).json({
    message: "Internal server error"
});

A simple way to remember:

4xx → Problem with the request

5xx → Problem on the server

16. What Does an HTTP Response Look Like?

An HTTP response can contain:

Status Code
Headers
Body

Example:

HTTP/1.1 200 OK
Content-Type: application/json

{
    "message": "Products fetched successfully"
}

Here:

200 OK

is the status code.

Content-Type: application/json

is a response header.

And:

{
    "message": "Products fetched successfully"
}

is the response body.

17. HTTP and JSON

Modern web applications commonly use JSON to exchange data.

JSON stands for:

JavaScript Object Notation

Example:

{
    "id": 1,
    "name": "Keyboard",
    "price": 2000
}

An Express server can send JSON using:

res.json({
    id: 1,
    name: "Keyboard",
    price: 2000
});

The frontend can then read the response.

const response = await fetch("/api/products");

const data = await response.json();

console.log(data);

18. Sending HTTP Requests with JavaScript

The browser provides the fetch() API for making HTTP requests.

For example:

const response = await fetch("/api/products");

const data = await response.json();

console.log(data);

The flow is:

JavaScript
    ↓
fetch()
    ↓
HTTP Request
    ↓
Server
    ↓
HTTP Response
    ↓
response.json()
    ↓
JavaScript

19. Sending Data with POST

We can also send data to the server using fetch().

const response = await fetch("/api/products", {
    method: "POST",

    headers: {
        "Content-Type": "application/json"
    },

    body: JSON.stringify({
        name: "Keyboard",
        price: 2000
    })
});

const data = await response.json();

console.log(data);

Let's understand this.

Method

method: "POST"

We are sending a POST request.

Headers

headers: {
    "Content-Type": "application/json"
}

We are telling the server that the request body contains JSON.

Body

body: JSON.stringify({
    name: "Keyboard",
    price: 2000
})

JSON.stringify() converts the JavaScript object into a JSON string that can be sent in the request body.

20. How Express Receives the Request

Now let's connect HTTP with Node.js and Express.

const express = require("express");

const app = express();

app.use(express.json());

app.post("/api/products", (req, res) => {
    console.log(req.body);

    res.status(201).json({
        message: "Product created",
        product: req.body
    });
});

app.listen(3000, () => {
    console.log("Server running on port 3000");
});

If the frontend sends:

{
    "name": "Keyboard",
    "price": 2000
}

Express receives it through:

req.body

and sends a response using:

res.json()

This is the basic connection between an HTTP request and an Express route.

21. Request → Server → Database → Response

In a real application, the server may need to communicate with a database.

For example:

app.get("/api/products", async (req, res) => {
    try {
        const products = await Product.find();

        res.status(200).json(products);
    } catch (error) {
        res.status(500).json({
            message: "Something went wrong"
        });
    }
});

The flow is:

GET /api/products
        ↓
Express receives request
        ↓
Route matches
        ↓
Product.find()
        ↓
MongoDB returns data
        ↓
Express creates response
        ↓
Client receives JSON

This is a common flow in MERN applications.

22. Complete HTTP Flow in a MERN Application

Let's look at a complete example.

Suppose a React application wants to display products.

Step 1 — React sends a request

const response = await fetch("/api/products");

const products = await response.json();

Step 2 — HTTP request is created

Conceptually:

GET /api/products HTTP/1.1
Accept: application/json

Step 3 — Express receives the request

app.get("/api/products", async (req, res) => {

Step 4 — Backend communicates with MongoDB

const products = await Product.find();

Step 5 — Server sends the response

res.status(200).json(products);

Step 6 — React receives the data

const products = await response.json();

Step 7 — React displays the data

The UI can now render the products.

The complete flow:

React
  ↓
fetch()
  ↓
HTTP GET Request
  ↓
Express
  ↓
Route
  ↓
Business Logic
  ↓
MongoDB
  ↓
JSON Response
  ↓
React
  ↓
UI

23. HTTP is Stateless

One important property of HTTP is that it is stateless.

Stateless means that each request is treated independently.

For example:

Request 1:
GET /api/products

Request 2:
GET /api/products/10

The second request does not automatically remember everything about the first request.

If an application needs to maintain information about a user between requests, it can use mechanisms such as:

Cookies
Sessions
Tokens
JWT
Server-side storage

This becomes important when implementing authentication.

We will explore authentication and JWT in later parts of this series.

24. HTTP vs HTTPS

You have probably seen URLs like:

http://example.com

and:

https://example.com

HTTPS is HTTP protected using TLS.

With HTTPS, communication between the client and server is encrypted.

Conceptually:

HTTP

Client
  ↓
Request
  ↓
Server

With HTTPS:

Client
  ↓
Encrypted communication
  ↓
Server

HTTPS is important when sending sensitive information such as:

Passwords
Authentication tokens
Personal information
Payment-related information

We already discussed TLS at a high level in Part 1.

25. How Developers Debug HTTP Requests

When building frontend and backend applications, the browser's Network tab is one of the most useful debugging tools.

Open:

Browser
   ↓
Developer Tools
   ↓
Network

Then make an API request.

You can inspect:

Request URL
Request Method
Status Code
Request Headers
Request Payload
Response Headers
Response Body

For example:

Request URL:
http://localhost:3000/api/products

Request Method:
GET

Status Code:
200 OK

You can also inspect the JSON response.

This is extremely useful when debugging API problems.

26. Common HTTP Problems

404 Not Found

You may have requested the wrong endpoint.

For example, your backend has:

/api/products

but your frontend requests:

/api/product

The server may return:

404 Not Found

400 Bad Request

The request data may be invalid.

For example:

{
    "price": "hello"
}

when the server expects a number.

401 Unauthorized

The request requires authentication, but valid authentication credentials were not provided.

403 Forbidden

The user is authenticated but does not have permission to access the resource.

500 Internal Server Error

Something went wrong while processing the request on the server.

When this happens, check your backend logs.

27. A Simple Mental Model for HTTP

If you're learning backend development, remember this:

               HTTP REQUEST
                     |
      +---------+----+----+---------+
      |         |         |         |
      v         v         v         v
   Method      URL     Headers    Body
      |         |         |         |
      +---------+----+----+---------+
                     |
                     v
                  SERVER
                     |
                     v
               HTTP RESPONSE
                     |
         +-----------+-----------+
         |           |           |
         v           v           v
    Status Code   Headers      Body

For example:

POST /api/products
Content-Type: application/json

{
    "name": "Keyboard",
    "price": 2000
}

The server processes the request and might return:

HTTP/1.1 201 Created
Content-Type: application/json

{
    "message": "Product created successfully"
}

That's the basic request-response cycle.

28. A Small REST API Example

Let's combine what we have learned into a simple Express API.

const express = require("express");

const app = express();

app.use(express.json());

const products = [
    {
        id: 1,
        name: "Keyboard",
        price: 2000
    },
    {
        id: 2,
        name: "Mouse",
        price: 1000
    }
];

// GET all products
app.get("/api/products", (req, res) => {
    res.status(200).json(products);
});

// GET one product
app.get("/api/products/:id", (req, res) => {
    const id = Number(req.params.id);

    const product = products.find((item) => item.id === id);

    if (!product) {
        return res.status(404).json({
            message: "Product not found"
        });
    }

    res.status(200).json(product);
});

// Create product
app.post("/api/products", (req, res) => {
    const product = {
        id: products.length + 1,
        name: req.body.name,
        price: req.body.price
    };

    products.push(product);

    res.status(201).json(product);
});

// Delete product
app.delete("/api/products/:id", (req, res) => {
    const id = Number(req.params.id);

    const index = products.findIndex((item) => item.id === id);

    if (index === -1) {
        return res.status(404).json({
            message: "Product not found"
        });
    }

    products.splice(index, 1);

    res.status(200).json({
        message: "Product deleted successfully"
    });
});

app.listen(3000, () => {
    console.log("Server running on port 3000");
});

This small API demonstrates:

GET
POST
DELETE
URL parameters
Request body
Status codes
JSON responses
Express routes

29. The Big Picture

Let's put everything together.

When you click a button in a web application, something like this can happen:

                  USER
                    |
                    v
                REACT UI
                    |
                    v
                 fetch()
                    |
                    v
              HTTP REQUEST
                    |
        +-----------+-----------+
        |           |           |
        v           v           v
     Method      Headers      Body
        |           |           |
        v           v           v
      POST    Content-Type      |
              Authorization     |
        |           |           |
        +-----------+-----------+
                    |
                    v
             EXPRESS SERVER
                    |
                    v
                  ROUTE
                    |
                    v
             BUSINESS LOGIC
                    |
                    v
                 MONGODB
                    |
                    v
             SERVER RESPONSE
                    |
                    v
              HTTP RESPONSE
                    |
                    v
                  REACT
                    |
                    v
                UI UPDATE

This is the basic communication cycle behind many modern web applications.

30. What You Should Remember

You don't need to memorize every part of the HTTP specification.

Start with these concepts:

HTTP
 ↓
Request / Response
 ↓
HTTP Methods
 ↓
Headers
 ↓
Request Body
 ↓
Query Parameters
 ↓
URL Parameters
 ↓
Status Codes
 ↓
JSON
 ↓
REST APIs
 ↓
Express

For example:

GET /api/products?page=2

means:

GET → retrieve data
/api/products → endpoint
page=2 → query parameter

And:

POST /api/products
Content-Type: application/json

{
    "name": "Keyboard",
    "price": 2000
}

means:

POST → send data, commonly to create a resource
/api/products → endpoint
Content-Type → request contains JSON
Request body → product data

Conclusion

HTTP is one of the fundamental building blocks of web development.

Every time your frontend communicates with your backend, HTTP is usually involved.

Once you understand:

Request
   ↓
Method
   ↓
URL
   ↓
Headers
   ↓
Body
   ↓
Server
   ↓
Response
   ↓
Status Code
   ↓
Response Body

APIs become much easier to understand and debug.

In a MERN application, the flow can look like:

React
   ↓
HTTP Request
   ↓
Node.js + Express
   ↓
Business Logic
   ↓
MongoDB
   ↓
HTTP Response
   ↓
React

Understanding this flow gives you a strong foundation for backend development.

Final Takeaway

HTTP may look simple from the outside:

Request → Response

But inside a real application, that request passes through multiple layers:

Frontend
   ↓
HTTP
   ↓
Express
   ↓
Business Logic
   ↓
Database
   ↓
HTTP
   ↓
Frontend

Once you understand this flow, you're not just using APIs anymore — you understand what is happening behind them.

References

If you want to go deeper into HTTP and web development, these are useful references:

HTTP Semantics — RFC 9110
HTTP — MDN Web Docs
HTTP request methods — MDN Web Docs
HTTP response status codes — MDN Web Docs
Fetch API — MDN Web Docs

What Happens When You Enter a URL?

Aryan Gupta — Thu, 01 Oct 2026 06:36:12 +0000

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:

For HTTP, the default port is:

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."