What happens after you type a URL and press enter?
The Short Answer
When you type a URL and press enter, the browser performs DNS resolution to find the server's IP address, establishes a TCP connection (with TLS if HTTPS), sends an HTTP request, receives the response, and then parses and renders the HTML into a visible page. Each step involves multiple sub-systems — from OS-level caches to network protocols to the browser's rendering engine.
Step 1: URL Parsing and Cache Check
The browser first parses the URL into its components (protocol, domain, path, query params) and checks if it has a cached response for this exact URL. If a valid cached response exists and hasn't expired (based on Cache-Control headers), the browser can skip the network entirely and render from cache.
- Parse URL into protocol, host, port, path, query string
- Check browser HTTP cache (memory cache, disk cache)
- If cache hit with valid expiry → render directly from cache
- If no cache or expired → proceed to DNS resolution
Step 2: DNS Resolution
The browser needs to convert the domain name (like example.com) into an IP address. It checks multiple caches in order before making actual DNS queries. Each cache level can short-circuit the process if it has a fresh record.
- Browser DNS cache (recently resolved domains)
- Operating system DNS cache
- Router cache
- ISP's recursive DNS resolver
- If not cached anywhere, full recursive lookup:
- Root nameserver → TLD nameserver (.com) → Authoritative nameserver
- Returns the IP address (e.g., 93.184.216.34)
DNS prefetching
Modern browsers prefetch DNS for links on the current page using <link rel="dns-prefetch">. By the time you click a link, the IP is often already resolved.
Step 3: TCP Connection + TLS Handshake
With the IP address in hand, the browser establishes a TCP connection using a three-way handshake. If the URL uses HTTPS (which most sites do today), a TLS handshake follows immediately to establish an encrypted channel. This adds latency but ensures data integrity and privacy.
- TCP three-way handshake:
- Client sends SYN
- Server responds with SYN-ACK
- Client sends ACK — connection established
- TLS handshake (for HTTPS):
- Client sends supported cipher suites and TLS version
- Server responds with chosen cipher and its certificate
- Client verifies certificate against trusted CAs
- Both sides derive session keys — encrypted channel ready
Step 4: HTTP Request and Response
The browser sends an HTTP request over the established connection. The request includes the method (GET), path, headers (cookies, accept types, user-agent), and potentially a body. The server processes the request and returns a response with a status code, headers, and the HTML body.
--- REQUEST ---
GET /search?q=javascript HTTP/2
Host: example.com
Accept: text/html
Cookie: session=abc123
User-Agent: Mozilla/5.0 ...
--- RESPONSE ---
HTTP/2 200 OK
Content-Type: text/html; charset=UTF-8
Cache-Control: max-age=3600
Content-Encoding: gzip
<!DOCTYPE html>
<html>...</html>
The response headers tell the browser how to handle the content — caching rules, content type, encoding, security policies (CSP, HSTS), and more. The browser decompresses the body if needed and begins parsing.
Step 5: Parsing and Rendering
Once the browser receives the HTML, it kicks off the critical rendering path — a multi-stage pipeline that transforms raw bytes into pixels on screen. This is where the browser's rendering engine does the heavy lifting.
- Parse HTML → build DOM tree
- Tokenizer converts bytes to tokens, parser builds the tree
- Parse CSS → build CSSOM tree
- Stylesheets (linked and inline) are parsed into a style tree
- Combine DOM + CSSOM → Render tree
- Only visible elements included (no display:none, no <head>)
- Layout (reflow)
- Calculate exact position and size of every element
- Paint
- Fill in pixels — colors, text, images, borders, shadows
- Composite
- Layer compositing for transforms, opacity, z-index
Subresource Loading
As the HTML parser encounters external resources — CSS files, JavaScript, images, fonts — it triggers additional requests. CSS and synchronous JS block rendering (the browser can't paint until they're loaded and processed). Images and async scripts load in parallel without blocking.
| Resource | Blocks parsing? | Blocks rendering? | Priority |
|---|---|---|---|
| CSS (<link>) | No | Yes | High |
| JS (<script>) | Yes | Yes | High |
| JS (async) | No | No | High |
| JS (defer) | No | No (runs after parse) | Medium |
| Images | No | No | Low |
| Fonts | No | Can cause FOIT/FOUT | Medium |
The Complete Flow
Here's the entire journey condensed into a single sequence. In practice, many of these steps overlap — modern browsers are highly optimized to start rendering as early as possible while still loading resources in parallel.
- URL parsed → cache checked
- DNS resolution → IP address obtained
- TCP handshake → connection established
- TLS handshake → encrypted channel ready
- HTTP request sent → response received
- HTML parsed → DOM built
- CSS parsed → CSSOM built
- Render tree → Layout → Paint → Composite
- JavaScript executed → page interactive
Why Interviewers Ask This
This is one of the most popular frontend interview questions because it touches nearly every layer of web technology — networking, security, browser internals, and performance. Interviewers use it to gauge the breadth of your knowledge and see how deep you can go on any particular step. A strong answer covers the full flow at a high level and then dives deep into one or two areas (like the rendering pipeline or TLS) to show expertise.
Quick Revision Cheat Sheet
DNS: Domain → IP address (browser cache → OS → ISP → recursive lookup)
TCP: Three-way handshake (SYN → SYN-ACK → ACK)
TLS: Certificate verification + session key exchange for encryption
HTTP: Request (method, headers, body) → Response (status, headers, body)
Rendering: HTML→DOM, CSS→CSSOM, Render tree→Layout→Paint→Composite
Blocking resources: CSS blocks render, sync JS blocks parsing, async/defer don't block