What Happens When You Type a URL and Press Enter

It is the most common interview question in web development for a reason: answering “what happens when you type a URL and press Enter” honestly forces you to touch nearly every layer of the network stack. Here is the whole journey, kept at a level where each step actually makes sense.

From keystrokes to an IP address

The browser first parses the URL. A string like https://example.com/path?q=1 is broken into a scheme (https), a host (example.com), an optional port (defaulting to 443 for HTTPS, 80 for HTTP), a path, and a query string. If what you typed is not a valid URL — say, just weather — the browser hands it to your default search engine instead.

Next comes DNS resolution, because the network routes packets to IP addresses, not names. The browser checks a series of caches before asking anyone: its own in-memory cache, then the operating system’s cache (and your hosts file). On a miss, it asks a recursive resolver — usually run by your ISP or a public service like 1.1.1.1 or 8.8.8.8. If the resolver does not have the answer cached, it walks the hierarchy: it queries a root nameserver, which points to the TLD nameserver for .com, which points to the authoritative nameserver for example.com, which finally returns the IP. Each record carries a TTL that controls how long it may be cached, so most lookups never reach the authoritative server at all.

Opening a connection: TCP and TLS

With an IP in hand, the browser opens a TCP connection using the three-way handshake: it sends a SYN, the server replies SYN-ACK, and the browser answers ACK. After that round trip, both sides have a reliable, ordered byte stream.

For https://, a TLS handshake runs on top of TCP before any HTTP data flows. The client and server agree on a protocol version and cipher suite, the server presents its certificate (which the browser validates against trusted certificate authorities and the hostname), and they derive the symmetric keys used to encrypt the session. TLS 1.3 streamlined this to roughly one round trip, with a “0-RTT” resumption mode for repeat visits. Everything after this point is encrypted.

The request, the response, and rendering

Now the browser sends the HTTP request, typically a GET for the path, along with headers like Host, User-Agent, Accept, and any cookies. The server processes it and returns a response: a status line (200 OK, 301 Moved Permanently, 404 Not Found), response headers (Content-Type, Cache-Control, Set-Cookie), and the body — usually the HTML document.

GET /path?q=1 HTTP/1.1
Host: example.com
Accept: text/html

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: max-age=3600

The browser then parses the HTML and builds the DOM (Document Object Model), a tree of nodes representing the page. As it parses, it discovers references to subresources — CSS, JavaScript, images, fonts — and fetches each one, often over the same connection. CSS is parsed into the CSSOM; the two trees combine into a render tree, the browser computes layout (the geometry of every box), and finally paints pixels to the screen. JavaScript can block parsing or modify the DOM along the way, which is why script placement and async/defer matter for how fast a page becomes usable.

Caching layers sit over this entire flow. The browser may serve the document or its assets straight from its HTTP cache based on Cache-Control and validation headers like ETag. A CDN may answer from an edge node. The server may pull from an application or database cache. The fastest request is the one that never has to travel.

FAQ