What Happens When You Type a URL

The complete technical journey from keystroke to rendered page, in full detail

The Interview Question

"What happens when you type a URL into your browser and press Enter?" It's the most famous interview question in software engineering. The answer can be as short as one sentence or as long as a book. It touches every layer of the computing stack — from hardware interrupts to application-level rendering. Let's trace the complete journey.

Step 1: The Keyboard

It starts with a physical keypress. When you press Enter, the keyboard controller detects the keyswitch state change and sends a scan code via USB (or PS/2 on older systems) to the computer's USB host controller. The host controller triggers a hardware interrupt (IRQ), causing the CPU to pause its current work and execute the keyboard interrupt handler in the operating system's kernel.

The kernel's input subsystem translates the scan code into a key event and delivers it to the foreground application — in this case, your browser. The browser's event loop processes the key event, determines that it was Enter pressed in the URL bar, and initiates navigation.

Step 2: URL Parsing

The browser parses the text you typed. If it looks like a URL, it proceeds with navigation. If it doesn't contain a scheme (like https://), the browser may prepend one, or it may treat the input as a search query and redirect to your default search engine.

A full URL has the structure: scheme://host:port/path?query#fragment. The browser extracts each component. For https://www.example.com/page?id=42, it identifies HTTPS as the protocol, www.example.com as the host, /page as the path, and id=42 as the query parameter.

Step 3: HSTS Check

Before making any network request, the browser checks its HSTS (HTTP Strict Transport Security) preload list and cached HSTS entries. If the domain is on the list, the browser will only use HTTPS, even if you typed http://. This prevents SSL stripping attacks. Major domains like google.com are on the preload list that ships with every browser.

Step 4: DNS Resolution

The browser needs an IP address. It checks its own DNS cache, then the OS cache, then sends a query to the configured recursive DNS resolver. The full DNS resolution process — querying root servers, TLD servers, and authoritative servers — can involve multiple round trips but typically completes in under 100 milliseconds. For popular domains, the answer is almost always cached somewhere.

Modern browsers also support DNS prefetching: when you load a page, the browser preemptively resolves domains for links on that page, so if you click one, the DNS step is already done.

Step 5: TCP Connection

Armed with an IP address, the browser initiates a TCP connection. This requires the famous three-way handshake:

1. SYN: The client sends a synchronization packet to the server.
2. SYN-ACK: The server acknowledges and sends its own synchronization.
3. ACK: The client acknowledges the server's response.

Each of these is a round trip. On a connection with 50ms latency, the handshake alone takes about 150ms. This is why TCP connection reuse (via HTTP keep-alive and connection pooling) matters so much for performance.

Step 6: TLS Handshake

For HTTPS connections (which is nearly all web traffic today), a TLS handshake follows the TCP handshake. With TLS 1.3 (the current standard), this adds one more round trip:

1. ClientHello: The browser sends supported cipher suites, a random number, and a key share.
2. ServerHello: The server chooses a cipher suite, sends its certificate, and completes the key exchange.

The browser verifies the server's certificate against its trusted certificate authorities (CAs). It checks that the certificate matches the domain, hasn't expired, hasn't been revoked (via OCSP or CRL), and chains to a trusted root. If any check fails, you see the dreaded "Your connection is not private" error.

After the handshake, all subsequent traffic is encrypted with symmetric encryption (typically AES-256-GCM or ChaCha20-Poly1305).

Step 7: HTTP Request

The browser sends an HTTP request through the encrypted TLS connection:

GET /page?id=42 HTTP/2
Host: www.example.com
User-Agent: Mozilla/5.0 ...
Accept: text/html,application/xhtml+xml,...
Accept-Encoding: gzip, br
Cookie: session=abc123

With HTTP/2 (used by most modern sites), multiple requests can be multiplexed over a single TCP connection. Headers are compressed with HPACK. With HTTP/3, the underlying transport switches from TCP to QUIC (built on UDP), eliminating head-of-line blocking entirely.

Step 8: Server Processing

The request arrives at the server — possibly after passing through a CDN (like Cloudflare or AWS CloudFront), a load balancer, and a reverse proxy (like Nginx). The web application processes the request: consulting databases, calling APIs, applying business logic, and generating a response.

For a typical web application, this involves:

• Routing the request to the correct handler
• Authenticating the user (checking the session cookie)
• Querying a database (PostgreSQL, MySQL, etc.)
• Rendering a template (server-side) or returning JSON (for SPAs)
• Setting response headers (caching, security, content type)

Step 9: HTTP Response

The server sends back a response:

HTTP/2 200 OK
Content-Type: text/html; charset=utf-8
Content-Encoding: br
Cache-Control: max-age=3600
Content-Length: 24817

Followed by the response body — the HTML document, compressed with Brotli (indicated by Content-Encoding: br).

Step 10: HTML Parsing and the Critical Rendering Path

The browser receives the HTML and begins parsing it into a DOM (Document Object Model) tree. This is not a simple sequential process — the parser must handle:

• CSS: When the parser encounters a <link rel="stylesheet"> tag, it fetches the CSS file and constructs the CSSOM (CSS Object Model). CSS is render-blocking — the browser won't paint anything until the CSSOM is built.

• JavaScript: When the parser hits a <script> tag, it must (by default) stop parsing, fetch the script, and execute it, because JavaScript can modify the DOM. The async and defer attributes change this behavior, allowing the parser to continue while scripts load.

• Images, fonts, and other resources: These are fetched in parallel but don't block parsing.

Step 11: Rendering

Once the DOM and CSSOM are ready, the browser combines them into a render tree — a tree of visible elements with their computed styles. Elements with display: none are excluded.

The render tree goes through several phases:

1. Layout (also called "reflow"): The browser calculates the position and size of every element. This is where CSS box model calculations happen.

2. Paint: The browser fills in pixels — text, colors, borders, shadows, images.

3. Compositing: Layers (created by transforms, opacity, fixed positioning, etc.) are composited together in the correct order, often using the GPU for performance.

Modern browsers use a multi-process architecture. Chrome runs each tab in a separate renderer process, with GPU compositing in yet another process. This isolation improves security and stability — a crash in one tab doesn't bring down the browser.

Step 12: JavaScript Execution

If the page includes JavaScript (and nearly all modern pages do), the browser's JavaScript engine (V8 in Chrome, SpiderMonkey in Firefox, JavaScriptCore in Safari) executes it. The script may modify the DOM, make additional network requests (fetch, XMLHttpRequest), set up event listeners, and initialize the interactive behavior of the page.

For single-page applications (SPAs) built with React, Vue, or Angular, the initial HTML may be a near-empty shell. The JavaScript framework takes over, rendering the full UI client-side. This shifts work from the server to the browser but adds a dependency on JavaScript execution speed.

The Full Timeline

For a typical page load on a modern connection:

The Rendering Pipeline

Once the browser has the HTML, CSS, and JavaScript, it begins rendering the page through a multi-stage pipeline:

1. DOM construction: The HTML parser builds a Document Object Model (DOM) tree representing the page's structure.
2. CSSOM construction: The CSS parser builds a CSS Object Model (CSSOM) representing the page's styles.
3. Render tree construction: The browser combines the DOM and CSSOM into a render tree that includes only visible elements with their computed styles.
4. Layout: The browser calculates the exact position and size of each element in the render tree based on the viewport dimensions, element sizes, margins, padding, and positioning rules.
5. Paint: The browser fills in pixels, drawing text, colors, images, borders, and shadows.
6. Compositing: The browser combines painted layers into the final image displayed on screen. GPU acceleration is used for transforms, animations, and scrolling.

This pipeline runs every time something changes on the page: a CSS animation, a JavaScript DOM update, a window resize. Modern browsers optimize by batching changes, only re-rendering affected portions of the page, and offloading compositing to the GPU.

JavaScript can block the rendering pipeline. When the browser encounters a script tag, it pauses HTML parsing to download and execute the script (unless the script is marked async or defer). This is why performance best practices recommend placing scripts at the bottom of the page or using defer: it allows the HTML to parse and render before JavaScript executes.

What Can Go Wrong

The journey from URL to rendered page involves dozens of systems, each of which can fail:

DNS failures can prevent the domain from resolving at all. DNS cache poisoning can direct you to a malicious server. TCP connection failures can prevent the connection from establishing. TLS certificate errors can indicate a man-in-the-middle attack or simply an expired certificate. Server errors (500, 502, 503) indicate problems on the server side. Slow responses can trigger timeouts. Large payloads can exceed mobile data limits.

Each potential failure has its own symptoms, diagnostic tools, and remediation strategies. Understanding the full pipeline is essential for diagnosing why "the website is slow" or "the page won't load," because the root cause can be at any layer, from DNS resolution to JavaScript execution to CSS rendering.

Performance and Optimization

Every step in the URL-to-page journey introduces latency, and web performance engineering is the discipline of reducing that latency. The total time from navigation to a fully rendered page (Time to Interactive, or TTI) is the sum of DNS resolution, TCP connection, TLS handshake, server processing, data transfer, and browser rendering.

DNS prefetching tells the browser to resolve domain names before they are needed. Preconnect goes further, establishing the TCP connection and TLS handshake in advance. These hints are specified with link tags in the HTML head and can eliminate hundreds of milliseconds of latency for resources loaded from third-party domains. Resource hints are one of the lowest-effort, highest-impact performance optimizations available.

Connection reuse (HTTP keep-alive, HTTP/2 multiplexing) amortizes the cost of TCP and TLS setup across multiple requests. A single HTTP/2 connection can carry dozens of concurrent requests, eliminating the head-of-line blocking that plagued HTTP/1.1 and the workarounds (domain sharding, sprite sheets, CSS concatenation) that developers used to mitigate it.

Content Delivery Networks (CDNs) reduce latency by caching content at edge servers geographically close to users. When a user in Tokyo requests a page hosted in New York, the CDN serves the cached version from a Tokyo edge server, eliminating a 200ms round trip across the Pacific. CDNs also provide DDoS protection, TLS termination at the edge, automatic image optimization, and HTTP/3 support. Major CDN providers (Cloudflare, Akamai, Fastly, AWS CloudFront) handle a significant fraction of global internet traffic.

Compression reduces transfer time substantially. Gzip has been the standard for decades, but Brotli (developed by Google) achieves 15-25% better compression ratios for text content. Modern browsers support both formats, and servers negotiate the best available algorithm through the Accept-Encoding header. For static assets, compression can be performed at build time rather than on every request.

Browser caching stores previously fetched resources locally. The Cache-Control header tells the browser how long to keep a resource before checking with the server. The ETag header provides a fingerprint for conditional requests: the browser asks has this changed since I last fetched it and the server responds with either the new content or a 304 Not Modified status, saving bandwidth but not the round trip. Proper cache configuration is one of the most impactful performance optimizations: a cache hit eliminates DNS, TCP, TLS, server processing, and transfer time entirely.

Lazy loading defers the loading of off-screen resources (images, iframes, scripts) until they are needed. The loading lazy attribute on img and iframe elements tells the browser to delay fetching until the element is about to enter the viewport. This reduces initial page load time and saves bandwidth for content the user may never scroll to see. Combined with responsive images (srcset and sizes attributes), lazy loading ensures that users download only the resources they actually need at the appropriate resolution for their device.

Service workers add another layer of caching and offline capability. A service worker is a JavaScript file that runs in a separate thread and can intercept network requests, serve cached responses, and handle background sync. Progressive Web Apps (PWAs) use service workers to provide app-like offline experiences, push notifications, and instant loading from cached data.

HTTP/3 and QUIC

The latest evolution in the URL-to-page pipeline is HTTP/3, built on QUIC (a transport protocol originally developed by Google). QUIC replaces TCP with a UDP-based protocol that integrates TLS 1.3 encryption directly into the transport layer, eliminating the separate TLS handshake. A QUIC connection is established in a single round trip (or zero round trips for resumed connections), compared to the three round trips required for TCP plus TLS 1.3.

QUIC also solves the head-of-line blocking problem that persists in HTTP/2 over TCP. In HTTP/2, all streams share a single TCP connection. If a single TCP packet is lost, all streams are blocked until retransmission succeeds. QUIC provides independent stream-level flow control, so a lost packet on one stream does not affect others. This is particularly impactful on mobile networks where packet loss is common.

Key Takeaways

• A single URL request triggers a cascade of protocol interactions: DNS resolution, TCP handshake, TLS negotiation, HTTP request/response, and browser rendering.
• DNS resolution traverses a hierarchy from local cache to recursive resolver to root servers to TLD servers to authoritative servers.
• TLS provides encryption, integrity, and authentication through a handshake that negotiates cipher suites and validates certificates.
• HTTP has evolved through multiple versions (1.0, 1.1, 2, 3), each improving performance while maintaining backward compatibility.
• Browser rendering follows a pipeline: DOM construction, CSSOM construction, render tree, layout, paint, and compositing.
• Failures can occur at any layer, and diagnosing performance problems requires understanding the full pipeline.

Why This Matters

This question is popular in interviews not because the answer is useful trivia, but because it tests systems thinking. Every layer of the stack — hardware, OS, networking, security, protocols, application logic, rendering — is involved. A developer who understands this full chain can debug problems that span layers, optimize performance at the right level, and make informed architectural decisions.

The seemingly simple act of loading a web page involves billions of transistors, thousands of miles of fiber optic cable, dozens of protocols, and millions of lines of code working in concert. It's one of the most complex operations humans routinely perform, and it usually finishes before you can blink.