Behind the Click: The Hidden Journey of Your Data

Hey there developers. Have you ever wondered, What actually happens behind the scenes, when you click or type an URL and a new page appears?

From clicking the link to a fully loaded new webpage, it may seem magical to most of the people. But we, we are Computer Geeks, what’s magic for others, is a structured process for us. We don’t say magic we say protocol.
So in this article I’ll be explaining how the Internet works when you click on a URL. What steps your browser takes that lead to the new page appearing? We’ll be unlocking all the mysteries.
So sit back, relax and enjoy.
Understanding the Big Picture:
Before we discuss each step separately let’s understand what happens as a Big picture over view. That will help us to understand it more.
When you type a URL in your browser, what you’re basically doing is, sending a request to the server.
Which server, you ask?
The one that corresponds to the specific URL you typed or the link you clicked. For example, if you type — https://hashnode.com/@shouvik112, you’re essentially sending a request to the Hashnode server.
What you, as a user, are doing here is asking the server -
“Hey Hashnode server, can you please send me the profile of this user named shouvik112?”
And the server replies -
“Sure, let me check real quick. If your request is valid and the user exists, I’ll send that to you.”
If the server finds the request valid and the user exists, it sends the profile back to the user agent (the browser, in this case).

Yes, that’s what happens when you type a URL in your browser.
Well… not exactly like that. The process is simple to understand, but not that straightforward, and truth be told, it should be a complex anyways.
Why, you ask?
Because if data were that easy to access, it would also be easy to corrupt or unethically access and misuse it and also would be easy to have authentication issues.
That’s why, for security and many other reasons, there are multiple steps that happen between requesting and receiving the data.
So let’s try to understand
1. Initiating the request: clicking or typing the URL
When you type a URL in the browser, the browser collects some information from that URL. These pieces of information are called URL components, which the browser then uses to find and connect to the server.
Let’s understand one by one. The URL components that the Browser collects are:
We’ll use https://hashnode.com/@shouvik112 as our example site.
Protocol: The protocol that the URL is using. In our example the protocol is — HTTPS(Hyper Text Transfer Protocol Secure)
Domain: Browser also collects the Domain of your URL. Here
[Hashnode.com](<http://Hashnode.com>)is the Domain.On a daily basis we call the entire [
Hashnode.com](<http://Hashnode.com>)as domain. It’s not wrong rather easy for regular conversations. But there are layers to it.****
[Hashnode.com](<http://Hashnode.com>)is called “Fully Qualified Domain Name" (FQDN)Hashnode — is Second-Level Domain (SLD)
.com — is Top-Level Domain (TLD)
Path: Path is the location/route on the server. The "address" or "directions" to find something. In out example
/@shouvik112is the path. This is the specific address we are finding.

Now you might ask, “Why does the browser need to collect those URL components?”
Well to find and connect to the server.
“How?”
When you write https://hashnode.com/@shouvik112 You mean
via this https protocol.
In this hashnode.com Domain
look for this /@shouvik112
Let me elaborate.
After collecting the URL components. The Browser uses the domain hashnode.com to find the server over the internet. And then via https protocol (or whatever protocol is used) makes connection with that. (We’ll dig deeper about that later in the article)
2. DNS Look Up:
Now that Browser has collected all the URL components it proceeds to the next step. And what is that? It finds the website’s IP with help of the Domain.
You might be confused by now. Let me explain.
You have many contact numbers in your phone right? Do you memorize each of them? Matter of fact do you memorize any of them? The answer probably is “No”. You don’t remember any of the contact numbers. You just save the contact number with the corresponding name. And when ever you need to call someone you search it with the name and call.
This is exactly same for the internet as well.
You know when you type hashnode.com . This is for humans to understand. The actual address of the site is called IP address. Which may look like 104.21.22.67 . But If you or I were to remember the IP address of each website, it’d be impossible for us to remember all the websites we visit, right?
That's why we search by names.

But what about the actual IPs? They should be saved somewhere right? So that we can get them whenever we need to to visit a website?
There comes the DNS (Domain Name System). DNS is like the contacts app of your phone where all the IP addresses of each site are saved.

So when you search https://hashnode.com/@shouvik112 The browser collects URL components and then sends the Domain name hashnode.com to the DNS server as a request to find the IP. DNS finds the corresponding IP address and then sends it back to the browser as response.
And this entire process is called DNS Query.
Caching: Your Browser's Short-Term Memory
Think about this, You look up your brother's number in your contacts and give him a call. Next time you want to reach him, do you dig through your entire contact list again? Of course not, his number's right there in your recent calls.
That's exactly how DNS caching works.
Here's the thing, there are only 13 root DNS servers in the entire world. If your browser had to query them every single time you visited a website, the internet would crawl. It'd be slow, inefficient, and those servers would be absolutely hammered with requests.
So your browser does something smart, it remembers. After looking up a website's IP address once, it stores that information in its cache. The next time you visit that same site, your browser skips the whole DNS lookup dance and goes straight to the IP it already knows.
It's like speed dial for the internet. Simple, but it saves you precious milliseconds every time you click.

3. TCP connection:
Now that the browser has the IP address from DNS, we can ask for the data we want, right? Well... not quite yet!
Why?
Well because the browser needs to establish a connection with the server before it can ask for data.
And how does the browser form a connection with the Hashnode server? Through a process called the TCP Three-Way Handshake.

Think of it like two people starting a phone call. Before having a conversation, both need to confirm they can hear each other:
🧔: Hey, can you hear me? —— SYN
👨🦰: Yeah I can hear you. Can you hear me? —— SYN+ACK
🧔: Yes I can hear you. —— ACK
Now both people know the connection works and can start their conversation!
Here's how the three-way handshake works:
The browser sends a special message called a SYN (Synchronize) packet, which is like saying 'Hey, I want to connect!'
The Server accepts the request and if that’s a valid request, the server sends a response. The server responds with a SYN-ACK (Synchronize-Acknowledge), confirming it received the request and is ready to connect.
Finally when the client receives the Server’s response the browser sends a final ACK (Acknowledge), confirming the connection is established.
Why three steps?
This handshake ensures both the browser and server are ready and able to communicate.
This entire process is called 3 way handshake.
TLS / SSL:
This is an extra step for HTTPS protocol. Have you ever wondered what is the difference between HTTP and HTTPS? And Why is HTTPS considered more secure?
Well the reason is TLS / SSL. HTTP and HTTPS both follow the exact same procedure for data transmission. But HTTPS has one extra step. And that is TLS handshake, which occurs after the TCP connection is established.
SSL/TLS encryption is used to protect the transmitting data. This ensures that sensitive information such as passwords and payment details are secure and not be read or stolen by third parties.
This is why HTTPS considered more secure.
4. HTTP Request & Response: The Data Exchange
Now that the TCP connection (and TLS since it’s HTTPS) is established, the browser sends the HTTP request to retrieve the data.
This request contains
GET /@shouvik112 HTTP/1.1
Host: hashnode.com
User-Agent: Mozilla/5.0 (Chrome)
Accept: text/html
Accept-Language: en-US
Cookie: session_id=abc123
What it’s saying is:
GET : I want to retrieve data
/@shouvik112: "Give me this specific profile”
Host: "From hashnode.com"
And rest of the data fields represent their corresponding tasks (which are not important for us right now).

Server Receives and Validates the Request
Now Server receives and validates the data like this
✓ Valid HTTP request ✓ Path exists: /@shouvik112 ✓ Check permissions (is this profile public? is user logged in?)
Server Gathers Data from the Database
The server extracts the username shouvik112 from the path. Then, the server gathers data from the database:
User information (name, bio, profile pic)
Recent blog posts
Follower count
Statistics
Social links
Server Generates the HTML Response
Now with all the collected data, the server generates an HTML webpage for the profile. And then, it's time to send this as a response to the browser.
5. Send the Data to the User Agent (Browser)
Now that the sever has found the data, the browser requested for and prepared the HTML page for that, It’s time to send the data as a response to the Browser. But the entire data can not be sent in a single package, rather it’s broken into smaller chunks/packets. And those packets are sent to the browser.
Each packet contain part of the response, imagine the entire response as a whole pizza 🍪 and the data packets as the slice of it 🍕. Each packet can take different paths (routers, switches, and networks) than the other one to reach the destination.
When all the packets finally arrive at your device, the browser reassembles them in the correct order to recreate / reconstruct the full HTML page.
HTTP/HTTPS Protocol:
The data itself transmits by following HTTP/HTTPS (if encryption is enabled, for better security)
HTTP decides how data is received and sent. It works like a language between between Browser and Server.
HTTPS adds a layer of TLS encryption, adding extra security so that the data can not be stolen by any 3rd party.
role of CDNs
In many modern websites, not all data comes from the server itself. As the transaction with server has a transaction cost.
So some part of the data like images, CSS, JavaScript files, or videos are served by CDNs (Content Delivery Networks).
what is a CDN? A CDN is a network of servers distributed across different geographic locations that work together to deliver web content faster and more reliably to users.
Without CDN:
Your request travels all the way to New York.
The server responds, and the data travels back across the ocean.
Result: slow loading times.
With CDN:
The CDN has servers (called edge servers) all around the world — like one in Mumbai, Singapore, London, etc.
When you visit the site:
The CDN checks which edge server is closest to you (say, Mumbai).
If that edge server already has cached copies of the website’s assets (images, JS, CSS, etc.), it serves them instantly.
If not, it fetches them from the origin server once, stores them locally, and then serves all future requests from that location.

6. Rendering the Data: Browser Displays the Page
Now that the browser has received all the packets and reassembled them properly, it’s time to build the actual webpage you see on your screen.
But as always, the Browser doesn’t just show you the raw HTML on your screen. It goes through multiple steps before displaying the page on your screen.
Those steps are:
Parsing the HTML:
Initially the browser reads the HTML document top to bottom.
While reading the HTML document, the Browser creates DOM (Document Object Model) tree like structure that represents all the elements.
DOM is the blue print of the webpage, a structure that the browser uses to know which element exists where.
Loading CSS, and JS:
Now that the structure of the webpage is ready, the browser looks for the linked CSS and JS.
CSS defines how things look — colors, fonts, spacing, layouts, etc.
JavaScript adds interactivity — like animations, dynamic content, or form validation.
Constructing the Render Tree
Now that the HTML and CSS are processed, the browser merges them and creates a Render Tree. A visual representation of what will actually appear on screen.
Each node in the Render Tree represents something that will be drawn. For example, a button, an image, or a line of text.
Layout and Painting
Now the browser calculates where each element should appear (this step is called layout) and then paints them onto the screen pixel by pixel.
Think of this as the browser drawing the webpage like an artist painting a canvas, first sketching the layout, then filling in the colors and styles.
JavaScript Execution & Interactivity
Finally, the browser executes any JavaScript that manipulates the DOM, for example updating elements, handling button clicks, etc.
This is what makes the webpage come alive.

7. User Interaction: Sending Data Back to the Server
Once the page is displayed, the journey doesn’t end it continues through your interactions. Now users can interact with it by clicking buttons, filling out forms, or navigating between pages. This interaction triggers new requests, which begin the cycle all over again. When you fill out a form, like logging in, signing up, or performing a search, your browser packages the input data and sends it to the server.
Conclusion:
So the next time you click a link and a page instantly appears, remember, it’s not magic happening inside your browser. It’s millions of tiny packets racing across the internet, servers working behind the scenes, and protocols keeping everything in sync.
Knowing this journey helps you see the web not as a mystery, but as an interconnected system, a living network that connects people, ideas, and data around the world.