Everything That Happens Between Typing a URL and Seeing a Page

The Complete Journey from URL to Rendered Page

You type a URL into your browser's address bar and press Enter. On a fast connection, the page appears in under a second. But during that fraction of a second, your browser executes a remarkable number of operations.

This article walks through the entire process from typing https://example.com to seeing the rendered page, crossing every layer of the network stack. The exact same process runs behind the scenes when you visit IP Check-san.

Step 1: Parsing the URL

The browser first parses the input string.

• Protocol: https:// → Use HTTPS (port 443)
• Domain name: example.com → Needs to be resolved to an IP address via DNS
• Path: / (root when omitted) → The resource to request from the server

If the input is determined to be a search query rather than a URL, the browser redirects to the default search engine.

Step 2: DNS Resolution - Converting a Domain Name to an IP Address

The browser needs to know the IP address of example.com. DNS resolution is attempted in the following order.

1. Browser cache: The browser remembers IP addresses of recently visited domains
2. OS cache: If not in the browser, the OS DNS cache is checked
3. hosts file: /etc/hosts (Unix) or C:\Windows\System32\drivers\etc\hosts (Windows) is checked
4. DNS resolver: If none of the above have it, a query is sent to the configured DNS server (ISP default, or Cloudflare 1.1.1.1, etc.)

The DNS resolver queries hierarchically - root servers → .com TLD servers → example.com's authoritative servers - and ultimately obtains the IP address (e.g., 93.184.216.34). This process typically takes 10-100 ms. Understanding DNS vulnerabilities helps you grasp the risks at this stage.

Step 3: Establishing a TCP Connection - Three-Way Handshake

Once the IP address is known, the browser establishes a TCP connection to the server's port 443. A TCP three-way handshake takes place.

1. SYN: Client → Server: "I want to connect"
2. SYN-ACK: Server → Client: "Acknowledged, I'm ready too"
3. ACK: Client → Server: "Confirmed, let's start communicating"

These 3 exchanges consume 1 RTT (Round Trip Time). From Tokyo to a server in Los Angeles, that's about 100 ms. The latency you can observe with traceroute directly impacts this step.

Step 4: TLS Handshake - Establishing Encrypted Communication

For HTTPS, a TLS encryption layer is built on top of the TCP connection. In TLS 1.3, the following occurs.

1. ClientHello: The client sends supported cipher suites, TLS version, and a random value
2. ServerHello: The server selects a cipher suite and sends its TLS certificate
3. Certificate verification: The browser verifies the certificate's validity (CA trustworthiness, expiration date, domain name match)
4. Key exchange: A shared encryption key is generated via Diffie-Hellman key exchange

TLS 1.3 optimizes the handshake to complete in 1 RTT (TLS 1.2 required 2 RTTs). For reconnections to previously visited servers, 0-RTT (zero round trip) is possible.

Step 5: Sending the HTTP Request

With the encrypted connection established, the browser sends an HTTP request.

This request includes information such as the browser type, acceptable content formats, language settings, and cookies.

Step 6: Server Processing and Response

The server receives the request and returns HTML. Static sites serve files directly, while dynamic sites have the application server query databases to generate HTML.

The response includes an HTTP status code (200 OK, 301 Redirect, 404 Not Found, etc.) and security headers.

Step 7: Rendering - From HTML to Pixels

Even after the browser receives the HTML, multiple processing steps occur before the page is displayed.

1. HTML parsing: Convert HTML into a DOM (Document Object Model) tree
2. CSS parsing: Convert CSS into a CSSOM (CSS Object Model)
3. Render tree construction: Combine the DOM and CSSOM to build a tree of elements to display on screen
4. Layout: Calculate the position and size of each element
5. Paint: Convert each element to pixels and draw them on screen

During this process, if additional resources (CSS, JavaScript, images, fonts) are needed, the DNS resolution → TCP connection → TLS handshake → HTTP request cycle repeats for each one (HTTP/2 multiplexes connections to the same domain, improving efficiency). As browsers render increasingly complex media, verifying content authenticity becomes critical - learn how deepfake detection helps distinguish genuine content from AI-generated forgeries.

Summary - A Culmination of Technology Packed into Under a Second

The journey from typing a URL to seeing a rendered page spans nearly every major internet technology: DNS, TCP, TLS, HTTP, and HTML/CSS rendering. Each step covered in this article is an independent technical domain with its own deep history and design philosophy.

When you visit IP Check-san, try opening your browser's developer tools (F12) and checking the "Network" tab. You'll see the time spent on each stage - DNS resolution, TCP connection, TLS handshake, and HTTP request - visualized.