What Happens When You Click a URL? A Step-by-Step Guide

When you click a URL, your browser initiates a complex chain of events: it reads the address, finds the website’s server using DNS, establishes a secure connection, requests the page, and renders it on your screen—all in a fraction of a second.

That click feels instant, but behind the scenes, dozens of systems work together: DNS servers, TCP connections, TLS handshakes, and rendering pipelines. Understanding what happens when you click a link helps you appreciate the web’s engineering and troubleshoot issues like slow loading or broken pages.

In this guide, you’ll learn the complete step-by-step journey from click to screen, broken down into six clear phases.

TL;DR

When you click a URL, your browser reads the address and performs a DNS lookup to find the server’s IP address. It then establishes a TCP connection, followed by a TLS handshake if the site uses HTTPS. The browser sends an HTTP request, the server responds with the page content, and the browser parses, styles, lays out, paints, and composites the page. Finally, it fetches additional resources like images and scripts. All of this happens in 200–500 milliseconds.

Key Takeaways

• URL parsing — the browser splits the URL into protocol, domain, path, and parameters to understand what’s being requested.
• DNS resolution — the browser checks caches (browser, OS, hosts file) before querying DNS servers hierarchically (root, TLD, authoritative) to find the IP address.
• Connection establishment — a TCP connection is opened on port 80 (HTTP) or 443 (HTTPS), followed by a TLS handshake for secure sites.
• HTTP request and response — the browser sends a GET request, and the server responds with HTML and a status code like 200 (OK) or 404 (Not Found).
• Rendering pipeline — the browser builds the DOM tree, applies CSS styles, calculates layout, paints pixels, and composites layers to display the final page.
• Ongoing asset requests — the browser automatically fetches additional resources (CSS, JavaScript, images) as the page loads.

Step 1: Browser Reads and Parses the URL

When you click a link, the first thing your browser does is read the URL and break it down into its component parts.

Take this example URL:

https://www.example.com/products/page1?ref=newsletter

The browser parses it as follows:

• https:// — the protocol, which tells the browser how to communicate with the server. HTTPS means it should use encryption (TLS).
• www.example.com — the domain name, a human-friendly address for the server.
• /products/page1 — the path, indicating the specific resource or page requested.
• ?ref=newsletter — the query parameters, providing additional information like tracking codes.

Once the browser understands the URL, it moves to the next critical step: finding where this server lives on the internet.

Step 2: DNS Lookup — Translating the Domain to an IP Address

Computers communicate using IP addresses (like 192.0.2.1), not domain names. The browser needs to translate the domain into an IP address through a process called DNS resolution (Domain Name System).

Think of DNS as the internet’s phonebook. Here’s how the lookup works step by step:

1. Browser cache check — the browser first checks its own local DNS cache. If it visited this domain recently, it might have the IP address stored locally. This is the fastest possible lookup.
2. Operating system cache check — if the browser cache has no record, the operating system checks its own DNS cache, which is shared across all applications.
3. Hosts file check — the OS checks the local hosts file (a static text file where you can manually map domain names to IP addresses). This is often used for local development or testing.
4. Recursive resolver query — if none of the local caches have the record, the browser sends a DNS query to the recursive resolver (typically provided by your ISP or a public DNS like Cloudflare’s 1.1.1.1).
5. Root server query — the resolver queries a root nameserver. These servers don’t know specific IP addresses, but they direct the resolver to the correct Top-Level Domain (TLD) server based on the domain’s extension (.com, .org, etc.).
6. TLD server query — the resolver contacts the TLD server (e.g., the .com TLD server), which responds with the address of the domain’s authoritative nameserver.
7. Authoritative nameserver query — the resolver contacts the authoritative nameserver, which holds the actual DNS records for the domain. This server returns the IP address of the website’s server.

This entire DNS resolution process typically takes just a few milliseconds.

DNS responses are cached at multiple levels with Time-to-Live (TTL) values. A longer TTL means less frequent lookups but slower updates; a shorter TTL allows for quicker changes but more queries.

Step 3: Establish a Connection — TCP and TLS

Now that the browser has the server’s IP address, it needs to establish a connection. This happens in two phases for HTTPS sites.

TCP Connection

The browser opens a TCP (Transmission Control Protocol) connection with the server. This is like making a phone call—the browser sends a “SYN” (synchronize) packet, the server responds with “SYN-ACK” (acknowledgment), and the browser replies with “ACK.” This is called the TCP three-way handshake.

• For HTTP sites, the default port is 80.
• For HTTPS sites, the default port is 443.

TLS Handshake (for HTTPS)

If the site uses HTTPS, the browser and server perform a TLS handshake to establish an encrypted connection.

1. ClientHello — the browser sends a message listing the TLS versions and encryption methods it supports.
2. ServerHello and Certificate — the server responds, choosing the encryption method and sending its SSL/TLS certificate (which proves its identity).
3. Certificate verification — the browser verifies that the certificate is valid, hasn’t expired, and was issued by a trusted Certificate Authority.
4. Key exchange — the browser and server exchange keys to agree on a shared session key. This session key will encrypt all subsequent communication.
5. Encrypted communication — once the handshake is complete, all data exchanged is encrypted using the session key.

The TLS handshake typically adds 20–80ms of latency on well-configured servers. With TLS 1.3, the handshake is faster (1-RTT or even 0-RTT for returning visitors) and more secure.

Step 4: Send an HTTP Request

With the connection established, the browser sends an HTTP request to the server.

An HTTP request has three parts:

1. Request line — includes the HTTP method (like GET to retrieve data), the path, and the HTTP version.
2. Headers — metadata like the host name, user-agent (browser type), accepted content types, cookies, and more.
3. Optional body — data sent with methods like POST (e.g., form submissions).

Here’s a simplified example of a GET request for the homepage:

GET / HTTP/1.1
Host: www.example.com
Accept-Language: en
User-Agent: Chrome/120

When you click a link, the browser uses the GET method by default—it’s asking the server to retrieve the page.

Step 5: Server Responds

The web server receives the request, processes it, and sends back an HTTP response.

An HTTP response has three parts:

1. Status line — the HTTP version and a status code indicating the result.
2. Headers — metadata like content type (HTML, JSON, etc.), content length, caching instructions, and more.
3. Body — the actual content (e.g., the HTML of the webpage).

Common status codes include:

• 200 OK — the request succeeded, and the content is included.
• 301 Moved Permanently — the resource has been moved to a new URL (a redirect).
• 404 Not Found — the server couldn’t find the requested page.

Here’s a simplified example of a successful response:

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

<html>...page content...</html>

If the page includes additional resources like images, stylesheets, or JavaScript files, the browser will automatically make separate requests for each of them.

Step 6: Browser Renders the Page

Once the browser receives the HTML, it begins the rendering pipeline to display the page on your screen.

The rendering process involves several stages:

1. Parse HTML to build the DOM tree — the browser reads the HTML and constructs the Document Object Model (DOM), which represents the page’s structure and content.
2. Fetch and parse CSS to build the CSSOM — the browser loads CSS files and constructs the CSS Object Model (CSSOM), which represents all the styles for the page.
3. Combine DOM and CSSOM to create the Render Tree — the browser merges the DOM and CSSOM into the Render Tree, which contains only the elements that will be displayed.
4. Layout — the browser calculates the exact position and size of each element on the page. This is also called “reflow”.
5. Paint — the browser converts the Render Tree into pixels on the screen. It creates a display list of drawing commands for each layer.
6. Compositing — the browser assembles all the layers into the final image you see on the screen, sending it to the GPU for rendering.

These rendering stages can run multiple times as the page loads or as you interact with it—scrolling, clicking buttons, or submitting forms all trigger parts of this pipeline.

During this process, the browser also executes any JavaScript it encounters. JavaScript can modify the DOM and CSSOM, which can trigger additional layout, paint, and composite cycles.

Modern browsers use a multi-threaded architecture to keep the page responsive: the main thread handles JavaScript, styles, and layout, while separate threads handle parsing, compositing, and painting.

Everything from the moment you click the link to the page appearing on your screen typically takes between 200 and 500 milliseconds.

Frequently Asked Questions

What’s the difference between what happens when I click a link vs. type a URL?

The underlying process is nearly identical. The main difference is that clicking a link often includes the full URL, while typing a URL may trigger autocomplete or default to the homepage if you just type the domain. Both initiate the same DNS lookup, connection, and rendering pipeline.

Why does my browser sometimes show “Not Secure” for HTTP sites?

HTTP sites send data in plaintext, meaning anyone on the network could read it. Modern browsers flag these sites as “Not Secure” to warn you. HTTPS adds encryption via TLS, protecting your data from interception.

How long does the whole process from click to display take?

Typically 200 to 500 milliseconds, but it depends on network speed, server response time, DNS lookup time, and page size. A slow DNS lookup or large page can extend this to several seconds.

What’s the difference between a 301 and 302 redirect?

A 301 redirect indicates the page has permanently moved to a new URL. Search engines pass link equity to the new URL. A 302 redirect indicates a temporary move. Search engines keep the original URL indexed.

What does “DNS propagation” mean, and why does it take time?

DNS propagation is the time it takes for DNS changes to reach all the caches around the world. Because DNS records are cached with TTL values, some caches may still hold the old record until the TTL expires. This is why changes can take up to 24-48 hours to fully propagate.

Does every click on a link trigger a full DNS lookup?

No. Browsers, operating systems, and DNS resolvers all cache DNS records. If the same domain was visited recently, the IP address may be retrieved from a local cache, skipping the full hierarchical lookup.

Sources

• DEV Community — What Happens When You Click a Link
• DNS.COM — The Complete Process of Domain Name Resolution
• MDN Web Docs — A Typical HTTP Session
• Okta Developer — Establishing an SSL/TLS Session
• Chromium — The Rendering Critical Path
• UniLink — What Happens When You Click a Link in Bio

Have you ever noticed a particular stage taking longer than expected—like slow DNS lookups or a sluggish TLS handshake? Share your experience in the comments, and we’ll help you troubleshoot.