"From Click to Response: Exploring the Journey of Your Browser's Request to the Server"

Browsers, also known as web browsers or Internet browsers, are software applications installed on our devices that enable us to access the World Wide Web. You are using one right now to read this text.

There are many browsers in use today and as of 2026, the most used ones were: Google Chrome, Apple's Safari, Microsoft Edge and Firefox.

But how do they actually work and what happens from the moment we type a web address into the address bar until the page we are trying to access gets displayed on our screen?

Every time you visit a website, fill out a form, or click a button, your request takes an incredible journey across the internet. But what really happens when you enter a URL in your browser and hit "Enter"? Let’s dive deep into the path your data takes from the browser to the server and back.

Entering the URL and DNS Resolution

When you type a website address (e.g., www.example.com) into your browser and press Enter, the first step is to determine the IP address of the server hosting that website. This process is called DNS (Domain Name System) resolution.

Since computers communicate using IP addresses (e.g., 192.168.1.1 or 2606:4700:4700::1111 for IPv6), but humans prefer easy-to-remember domain names (www.example.com), DNS acts as the phonebook of the internet, converting domain names into IP addresses.

DNS Lookup (resolving the web address)

The first step in navigating to a web page is finding where the assets for that page are located, such as HTML, CSS, JavaScript, and other files. When you navigate to a website like https://example.com, the HTML page is located on a server identified by an IP address, such as 93.184.216.34. For humans, websites are represented by domain names, but for computers, they are identified by IP addresses. If you have never visited this site before, a Domain Name System (DNS) lookup is necessary to translate the domain name into the corresponding IP address.

DNS servers are computer servers that maintain a database of public IP addresses and their associated hostnames, similar to a phonebook that links people's names to their phone numbers. These servers primarily function to resolve or translate domain names into IP addresses upon request. Currently, there are over 600 different DNS root servers distributed globally.

When we request a DNS lookup, we actually query one of the DNS servers to find out which IP address corresponds to the domain name, such as https://example.com. If a corresponding IP address is found, it is returned to the browser. If the lookup is not successful, the browser will display an error message indicating that the domain could not be resolved.

The text you provided is a detailed explanation of the Domain Name System (DNS) and its components. Here's a concise summary:

The text you provided outlines the steps involved in the DNS lookup process. Here's a concise summary:

Browser Cache Check: The browser checks its local cache for a previously resolved IP address. If found, it skips the DNS lookup; if not, it proceeds to the next step.
Operating System (OS) Cache Check: The OS checks its DNS cache for the domain. If a match is found, it returns the IP address to the browser; if not, it forwards the request to the local DNS resolver (usually the router).
Router Cache Check: The router checks its DNS cache. If it finds a stored IP address, it returns it to the browser; if not, it forwards the request to the ISP’s DNS server.
ISP's Recursive DNS Server Query: The ISP’s recursive DNS resolver checks its cache. If it finds the IP, it sends it back to the browser; if not, it queries the Root DNS Server.
Contacting the Root DNS Server: The ISP's recursive resolver contacts a Root DNS Server, which directs the request to the TLD Name Server.
Contacting the TLD Name Server: The TLD Name Server receives the request and forwards it to the Authoritative DNS Server for the domain.
Contacting the Authoritative DNS Server: The Authoritative DNS Server holds the final IP address and sends it back to the ISP’s recursive DNS server.
Returning the IP Address to the Browser: The recursive DNS server caches the result and sends the IP address to the browser, which then establishes a connection to the web server.

Once the web browser knows the IP address of the website, it will try and set up a connection to the server holding the resources, via a TCP three-way handshake (also called SYN-SYN-ACK, or more accurately SYN, SYN-ACK, ACK, because there are three messages transmitted by TCP to negotiate and start a TCP session between two computers).

TCP (Transmission Control Protocol) Handshake

The TCP handshake is a process that establishes a connection between two entities, such as a browser and a server, before data transmission. If we imagine the browser and server as two people having a conversation, it would proceed as follows:
1. The browser (Person A) sends a "SYN" message to the server (Person B), indicating a request to start communication.
2. The server (Person B) responds with a "SYN-ACK" message, acknowledging the request and agreeing to communicate.
3. The browser (Person A) sends an "ACK" message back to the server (Person B), confirming the connection is established.

This three-step process ensures that both parties are ready to exchange data reliably.

The browser sends a SYN message to the server to initiate synchronization, which is the first step in establishing a TCP connection. This process is part of the TCP three-way handshake, where "SYN" stands for "synchronize."

The server will then reply with a SYN-ACK message, which stands for synchronization and acknowledgment. This is the second step in the TCP three-way handshake, where the server acknowledges the SYN message from the browser and agrees to establish a connection.

In the last step, the browser will reply with an ACK message. Now that the TCP connection (a two-way connection) has been established through the three-way handshake, the TLS negotiation can begin.

TLS negotiation

The text you provided is a detailed explanation of TLS negotiation. Here's a refined version:

TLS negotiation is essential for establishing secure connections over HTTPS. This process determines the encryption cipher, verifies the server, and ensures a secure connection before data transfer begins. Transport Layer Security (TLS), which succeeded the now-deprecated Secure Sockets Layer (SSL), is a cryptographic protocol that secures communications over networks. While TLS is widely used in applications like email and instant messaging, its most visible use is in securing HTTPS. Since applications can operate with or without TLS (or SSL), the client (browser) must request the server to establish a TLS connection.

During this step, some more message are exchanged between the browser and the server.

The text you provided is a detailed explanation of the TLS handshake process and the establishment of a secure connection using TCP/IP. Here's a refined version:
1. Client Hello: The browser initiates the TLS handshake by sending a message to the server. This message includes the supported TLS versions, cipher suites, and a random string of bytes known as the client random.
2. Server Hello and Certificate: The server responds with its SSL certificate, the chosen cipher suite, and another random string of bytes called the server random.
3. Authentication: The browser verifies the server's SSL certificate with the issuing certificate authority to ensure the server's identity.
4. Premaster Secret: The browser generates a premaster secret, encrypts it with the server's public key from the SSL certificate, and sends it to the server. Only the server can decrypt this with its private key.
5. Private Key Decryption: The server decrypts the premaster secret.
6. Session Keys Creation: Both the browser and server use the client random, server random, and premaster secret to generate session keys for encryption.
7. Client Finished: The browser sends a message indicating it has completed its part of the handshake.
8. Server Finished: The server responds, completing the handshake.
9. Secure Symmetric Encryption: The handshake is complete, and secure communication can proceed using the session keys.

Once the browser knows the server's IP address, it establishes a connection using TCP/IP:

TCP Handshake: A three-way handshake ensures a reliable connection:
- SYN: The browser requests to start communication.
- SYN-ACK: The server acknowledges and responds.
- ACK: The browser confirms and begins data transmission.
TLS/SSL Encryption: If HTTPS is used, the browser and server establish a TLS handshake to ensure data encryption and security.

Now that a secure connection is established, the browser sends an HTTP (Hypertext Transfer Protocol) request to the server. The request typically includes:

Method: (GET, POST, PUT, etc.) – defines the action.
Headers: Information like browser type, cookies, and authentication.
Body (for POST and PUT requests): Contains user data (e.g., form inputs).

For example, if you submit a login form, the browser sends a POST request with your credentials in the request body.

📩Requesting Data: The Letter Reaches the Post Office

Once the DNS lookup is complete and the browser knows the web server's IP address, the next step is to send a request to fetch the webpage. This process can be compared to mailing a letter, where the browser acts as the sender and the server is the recipient.

Breakdown: The HTTP Request Journey

1. Writing the Letter (Forming the HTTP Request)

Just like writing a letter, the browser prepares a structured request to be sent to the web server. The HTTP request includes:

Method: Defines the action (GET, POST, PUT, DELETE).
Headers: Extra information like browser type, cookies, authentication, etc.
Body: Contains data (only in POST and PUT requests).

🔹 Example HTTP Request (GET method)

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: keep-alive

This request asks the server to send back the index.html page of www.example.com.

2. Putting the Letter in an Envelope (Encapsulation in TCP Packets)

Before sending, the request is wrapped in multiple layers of network protocols:

HTTP request is placed inside a TCP packet (like putting a letter in an envelope).
TCP packet is placed inside an IP packet (adding the sender and receiver’s address).
IP packet is placed inside an Ethernet frame (preparing it for transport over the network).

Each layer helps in efficient and reliable data transmission.

3. Dropping the Letter at the Post Office (Reaching the ISP’s Network)

The browser hands over the request to the computer’s network interface.
The request is sent through the router to the ISP’s network, similar to dropping a letter in a mailbox.

At this stage, the request enters the vast internet infrastructure.

4. Sorting and Dispatching (Routing the Request to the Web Server)

Like a post office sorting and forwarding mail, the request is:

✔ Routed through multiple network routers using the IP address.
✔ Passed through undersea cables, satellites, or fiber optics if needed.
✔ Directed towards the data center hosting the website.

Each router along the way looks at the destination IP address and determines the best path to reach the web server.

5. Letter Arrives at the Recipient (The Web Server Receives the Request)

Finally, the request reaches the web server at the destination IP address. The server:

🔹 Reads the request headers (to understand what data is requested).
🔹 Processes authentication & security checks (if required).
🔹 Sends the request to the backend for processing.

At this point, the server is ready to prepare and send a response.

📬 Server Processing: Opening and Reading the Letter

Once the request reaches the web server, it acts like a post office receiving a letter. The server must open, read, and process the request before preparing a response.

Breakdown of Server Processing

1. Receiving the Request (Opening the Envelope)

The web server receives the request at its IP address on a specific port (usually port 80 for HTTP or 443 for HTTPS).
The transport layer (TCP) ensures the request arrived intact and without errors.
The server removes the outer layers (Ethernet, IP, TCP) to access the HTTP request inside.

2. Reading the Request (Checking the Letter’s Content)

The server parses the HTTP request to understand what the client (browser) wants.
It examines the method, such as:
- GET → Asking for a webpage or resource.
- POST → Sending data (e.g., login form, file upload).
- PUT/DELETE → Modifying or deleting data.

✔ Example Request (GET method)

vbnetCopy codeGET /index.html HTTP/1.1  
Host: www.example.com  
User-Agent: Chrome/120.0  
Accept: text/html

The server reads this request and understands that the user wants the index.html page.

3. Authentication & Security Checks (Verifying the Sender)

If authentication is required (e.g., logging into an account), the server checks credentials using:
- Cookies & Sessions – To track logged-in users.
- API Keys / Tokens – If it's an API request.
- User Permissions – To verify access rights.
The server also performs security checks:
- Firewall – Blocks malicious requests.
- Rate Limiting – Prevents too many requests from one client.
- Input Validation – Ensures no harmful code is sent (e.g., preventing SQL Injection).

4. Processing the Request (Passing to Backend & Database)

If the request needs dynamic content, the web server forwards it to a backend application (written in PHP, Python, Node.js, Java, etc.), which:

✔ Handles business logic (e.g., calculating data, checking conditions).
✔ Fetches data from a database (MySQL, MongoDB, PostgreSQL).
✔ Prepares the response (HTML, JSON, or other formats).

✔ Example Process:

A user requests profile.html → The backend fetches their data from the database → The server generates a dynamic HTML page with the user’s info.

5. Preparing the Response (Sealing the Reply Letter)

The server creates an HTTP response, including:
- Status Code (200 OK, 404 Not Found, 500 Internal Server Error).
- Headers (content type, caching, cookies).
- Response Body (HTML, JSON, or other data).

✔ Example Response:

lessCopy codeHTTP/1.1 200 OK  
Content-Type: text/html  
Content-Length: 1024  
Set-Cookie: session=abc123  

<html><body><h1>Welcome, User!</h1></body></html>

Now the server seals the response and sends it back to the client!

Request Response: Data Transfer from Server to Browser

Once the server collect’s data based upon your request it sends a response to the browser ( client ). The response is consist various various other things in addition to your requested data. So, let’s see what are the components of the Response.

Status line:- The status line is the first line in the response code. It consists of three parts: The HTTP Version, Response code & the Status method.

The example of the Status line is:

HTTP/1.1 200 OK

Status code:- It is an three digit number indicating the result of the request.

Here are some common response codes:

200 OK: Request successful, data returned.
201 Created: New resource created after successful request.
204 No Content: Request successful, but no content to send.
400 Bad Request: Malformed request.
404 Not Found: Resource not found.

Message body:- The message body consists the response or data requested by client if request is successful. For a response to an unsuccessful request, the message body might provide further information about the reasons for the error, or about some action the client needs to take to complete the request successfully.
Content Delivery Networks (CDNs): In some cases, data may pass through CDNs, which are distributed networks of servers located around the world. CDNs help deliver content faster by caching static resources like images and videos on servers closer to the user, reducing latency and speeding up the loading time.

Browser Rendering: Displaying the Data in Browser

When the data is reached to your browser, your browser process the data and displays it on your desktop screen. This process have serval steps which re following as:

HTML parsing, CSS styling and JavaScript work: The browser parses the HTML code, breaking it down into tokens and creating a DOM tree where each node represents an HTML element. The browser also parses CSS styles and combines them with the DOM to create a "render tree" which includes information about the layout and visual appearance of each element. Finally, the JavaScript is used to make the web page interactive .
DOM( Document Object Model) : As, we studied the DOM is tree where each node represents the HTML element. The browser uses the DOM is basically used to construct the looks or you can say the representation of the web page.
Rendering Engine: A rendering engine is a software that translates the code written in HTML, CSS and JavaScript to display elements on the screen.

Common Security Aspects During the Journey

Some common security aspects during the journey of data from the browser to the server and back include:

SSL/TLS Encryption: HTTPS sites use SSL/TLS encryption to protect the integrity of the data, ensuring that private information remains private. This encryption secures the data transmitted between the browser and the server.
Firewall: Many applications use firewalls to block unauthorized traffic from their servers. A firewall is a network security device that regulates incoming and outgoing network traffic to protect a network from unauthorized access and potential threats.
Authorization: Many applications use authorization to protect sensitive data by not granting access to unauthorized clients. It is usually paired with authentication, which is the process of verifying a user's identity. Authorization is based on various criteria, such as role, relationship, or attributes.