What Happens When You Type a URL

Typing a URL and pressing Enter triggers a complex chain of events: URL parsing, DNS resolution, TCP connection, TLS handshake, HTTP request, server processing, response rendering, and JavaScript execution — all happening in under a second.

What It Really Means

This is one of the most popular interview questions in software engineering because it tests breadth of knowledge across networking, operating systems, web architecture, and browser internals. A strong answer demonstrates understanding of every layer in the stack.

What seems like a simple action — typing "https://example.com" and pressing Enter — involves at least 10 distinct systems working together. Understanding this end-to-end flow helps you design better systems, debug network issues, and optimize application performance.

We will trace the complete journey of a request, from keyboard press to rendered page.

How It Works in Practice

Step 1: URL Parsing and HSTS Check

Step 2: DNS Resolution

Step 3: TCP Three-Way Handshake

Step 4: TLS Handshake

Step 5: HTTP Request

Step 6: Server Processing

Step 7: Response and Rendering

Complete Timeline

Implementation

Measuring each phase:

Curl timing breakdown:

Trade-offs

Optimization opportunities at each stage:

Common Misconceptions

• "The server is usually the bottleneck" — Network latency (DNS + TCP + TLS) often exceeds server processing time. A fast server behind a slow network still feels slow.
• "HTTPS adds significant overhead" — With TLS 1.3 and session resumption, HTTPS adds only 1 RTT for new connections and 0 RTT for resumed connections.
• "The page is loaded when the HTML arrives" — HTML is just the beginning. The browser must fetch CSS, JavaScript, images, fonts, and then parse, layout, paint, and execute JavaScript before the page is interactive.
• "DNS resolution always happens" — Browsers aggressively cache DNS. For frequently visited sites, DNS resolution is often skipped entirely.
• "All resources load sequentially" — HTTP/2 multiplexing and browser preloading enable parallel resource loading. Critical resources are prioritized.

How This Appears in Interviews

This question appears in almost every system design and networking interview. Here is how to structure your answer:

1. Start high-level: URL parsing, DNS, TCP, TLS, HTTP, server processing, rendering. Show you know the full stack.
2. Go deep on one area: Pick the area most relevant to the role. Backend roles: focus on server processing and database queries. Frontend roles: focus on rendering pipeline. Infrastructure roles: focus on DNS, CDN, and load balancing.
3. Mention optimizations: Show you understand performance tuning at each layer.
4. Connect to system design: "This is why we use a CDN — to reduce the DNS-to-first-byte latency for users far from the origin server."

Key things interviewers look for:

• Understanding of DNS hierarchy and caching
• Knowledge of TCP and TLS handshake costs
• Awareness of HTTP/2 and its benefits
• Understanding of browser rendering pipeline
• Ability to identify and optimize bottlenecks

Related Concepts

• DNS Resolution — step 2 of the URL lifecycle
• TCP Three-Way Handshake — step 3
• TLS/SSL Handshake — step 4
• HTTP/2 Multiplexing — how resources load in parallel
• CDN and Edge Computing — serving content closer to users
• CORS — browser security for cross-origin requests
• Tail Latency — why p99 latency matters for real user experience
• System Design Interview Guide
• Algoroq Pricing — access all concept deep-dives