What Happens When You Type a URL into a Browser?

Question and Scope

What happens from the moment a user enters https://shop.example/products?id=42#reviews in the address bar and presses Enter until the page becomes visible? Cover URL parsing, name resolution, connection security, HTTP, server-side handling, browser navigation, and rendering. Also explain which stages caching or connection reuse can skip.

Start with explicit assumptions so the answer does not drift between incompatible paths. This is a new top-level document navigation. The input is a complete URL, not a search query. No service worker supplies the response, no HTTP response is fresh enough to use directly, no compatible connection can be reused, the host needs resolution, and the final server response is HTML with status 200. Warm caches, redirects, and HTTP/3 become branches after that baseline.

This cross-layer fundamentals question fits backend, client, full-stack, infrastructure, SRE, and general software engineering interviews. The task is to derive the real path from cache and protocol assumptions, then map network, server, and rendering stages to observable evidence.

What the Interviewer Is Testing

First, can the candidate state assumptions before narrating a sequence? Memorizing “DNS, TCP, TLS, HTTP, render” misses caches, service workers, connection reuse, and HTTP/3. The actual path depends on navigation type, cached state, protocol negotiation, and the response. A strong answer establishes one deterministic baseline and then names the conditions that change it.

Second, can the candidate keep protocol boundaries accurate? #reviews is a URL fragment and is excluded from the HTTP request target. HTTPS has a default port of 443. DNS resolves a host but does not necessarily start at a root server on every navigation. HTTP/1.1 and HTTP/2 commonly use TCP; HTTP/3 uses QUIC, which runs over UDP and integrates TLS 1.3.

Third, can the candidate distinguish navigation commit, resource loading, and pixels on screen? Receiving the first byte does not make the page visible, and committing a navigation does not mean every resource is loaded. The browser still selects a renderer, parses HTML, discovers subresources, constructs the DOM and CSSOM, and performs style calculation, layout, paint, and compositing.

Fourth, can the candidate use the model to debug? A sequence alone cannot answer “where is it slow?” A high-quality answer maps DNS, connect, TLS, first byte, download, and main-thread rendering to evidence in navigation timing, the network panel, and a performance trace.

Questions to Clarify First

• Is the input definitely a URL? An address bar can send ordinary text to a search engine. This prompt supplies a complete HTTPS URL with a scheme, so continue as a navigation.
• Is this a document navigation or an in-app SPA transition? Calling history.pushState() does not automatically run the same cross-document navigation. The baseline is a new top-level document.
• Is this a cold or warm path? HTTP and DNS caches, a service worker, preconnect, or an existing HTTP/2 or HTTP/3 connection can remove stages. Explain the cold path first, then the branches.
• Which protocol and network environment apply? HTTP/1.1, HTTP/2, and HTTP/3 establish connections differently. A proxy, VPN, enterprise gateway, or unavailable UDP path can also change the route.
• What response comes back? A 200 HTML document, redirect, download, certificate error, and network failure take different branches. The baseline uses 200 HTML.
• What does “visible” mean? First paint, largest contentful paint, DOMContentLoaded, and load are different milestones. This answer reaches first visibility and then accounts for later loading.

30-Second Answer Framework

“I’ll assume a cold, top-level HTTPS navigation. The browser parses the URL and keeps the fragment client-side. It gets an address from cache or DNS, then reuses a connection or establishes TCP plus TLS for HTTP/1.1 or HTTP/2, or QUIC with integrated TLS 1.3 for HTTP/3. It sends the path and query. After checking the response and selecting a renderer, it commits the navigation. The renderer parses HTML, loads subresources, builds the DOM, CSSOM, and render tree, then performs layout, paint, and compositing. For a slow load, I separate DNS, connect/TLS, TTFB, download, and main-thread time.”

Step-by-Step Deep Dive

Step 1: Classify the address-bar input and parse the URL

The browser first decides whether the address-bar input is a navigable URL or a search query. This input contains https://, so it is parsed as a URL. The result is:

The browser also applies the URL Standard’s parsing and normalization rules and checks navigation policy. An old page’s unload handling, browser security policy, or an invalid URL can change the outcome before a network request begins. Pressing Enter is not synonymous with immediately sending packets.

Step 2: Determine whether network access can be avoided

A real browser considers existing document state, a service worker, the HTTP cache, preload state, and reusable connections. A fresh applicable cached response can avoid contacting the origin. A controlling service worker can return a cached response, perform its own fetch, or combine the two. Even a cache hit does not remove all browser work: the returned HTML may still need parsing and rendering.

The baseline assumes none of those shortcuts can supply the document, so network access continues. Avoid claiming one universal order such as “check every cache, then do DNS.” Response caches, DNS caches, and connection pools hold different state, and browser implementations can perform some work speculatively or in parallel.

Step 3: Resolve the host to a reachable address

The browser or operating system first uses a still-valid name-resolution result. On a miss, it asks the configured recursive resolver. That resolver also uses caches and follows DNS delegation only when it lacks an answer, eventually returning suitable address records. The result may lead to a CDN or edge server rather than the application origin.

Consequently, “the browser queries root, top-level-domain, and authoritative servers on every load” is inaccurate. The client normally delegates recursive work to a resolver, while caches and record TTLs determine whether further queries are needed. A browser may also use encrypted DNS. That changes the query’s transport and privacy boundary, not the underlying goal of mapping a host to a reachable service address.

Step 4: Reuse or establish a secure connection

With candidate addresses available, the browser first tries to reuse a connection compatible with the target. If none is available, the path depends on the selected HTTP version:

• HTTP/1.1 or HTTP/2 commonly establishes TCP and then performs a TLS handshake. TLS validates the certificate against the host, negotiates cryptographic parameters, and can use ALPN to select HTTP/2 or HTTP/1.1.
• HTTP/3 uses QUIC. QUIC runs over UDP and integrates the TLS 1.3 handshake into connection establishment, so a TCP three-way handshake is not universal to HTTPS.
• If a usable QUIC/UDP path is unavailable, a client can fall back to TCP-based HTTP. The exact race and fallback policy is browser implementation detail; do not invent one fixed timeline.

IP routing, the local link, NAT, a proxy, or a VPN can all participate in delivering packets. In a time-limited interview, acknowledge those layers without expanding every network hop unless the interviewer asks.

Step 5: Send HTTP and handle the server response

Once a connection is usable, the browser constructs the request. An HTTP/1.1 text representation captures the important semantics:

GET /products?id=42 HTTP/1.1
Host: shop.example
Accept: text/html

The request target includes the path and query, not #reviews. The browser decides whether to attach each cookie according to domain, path, SameSite, security, and related rules, and can add content-negotiation or cache-validation fields. “The browser sends all cookies” is too broad. HTTP/2 and HTTP/3 do not use this HTTP/1.1 wire format, but the method, target, fields, and response semantics have direct equivalents.

The request may reach a CDN, reverse proxy, or load balancer before an application, cache, and database. A simple server may answer directly. Treat those components as possible architecture, not mandatory stages. The response carries a status, fields, and content. A redirect starts a subsequent navigation toward the new location. A 304 Not Modified combines with an existing cached response. The baseline receives 200, an HTML content type, and a response body.

Step 6: Commit the browser navigation

As the response arrives, the browser handles its status, content type, download decision, and security policy, then chooses an appropriate renderer for the destination. Chromium distinguishes committing a navigation from loading the document. Commit transfers the response to a renderer and changes ownership of the current document; reading the remainder, parsing, scripts, and subresources can continue afterward.

An error status does not always mean “no page.” An HTML error response from the server can become the new document. A certificate failure, connection failure, or browser block can instead produce a browser-generated error page. Saying that navigation commits only for status 200 is too absolute.

Step 7: Parse, load, and put pixels on screen

The renderer incrementally parses HTML into the DOM. When it encounters stylesheets, scripts, fonts, images, and other references, it schedules subresource requests. Those resources can reuse DNS answers and connections, or come from other origins that require more name resolution and connection work. Each subresource does not inevitably repeat the full handshake sequence.

Parsing CSS produces the CSSOM. The DOM and CSSOM contribute to a render tree for visible content, followed by style calculation, layout, and paint; the browser then composites layers into displayed pixels. A classic script without suitable defer, async, or module behavior can block HTML parsing, and CSS affects first rendering. First paint can occur before every image or asynchronous script completes. DOMContentLoaded can also precede some subresources’ load completion.

The #reviews fragment was not sent to the server. Once the document can be targeted, the browser can scroll to the matching element. If script creates that element later, the eventual behavior also depends on page code.

Step 8: Diagnose “slow” with phase-specific evidence

First determine whether the user sees a DNS failure, connection failure, blank page, late content, or blocked interaction. Then map the symptom to stages:

A page can inspect its navigation record for initial triage:

const [nav] = performance.getEntriesByType("navigation");

console.table({
  dns: nav.domainLookupEnd - nav.domainLookupStart,
  connect: nav.connectEnd - nav.connectStart,
  ttfb: nav.responseStart - nav.requestStart,
  download: nav.responseEnd - nav.responseStart,
  protocol: nav.nextHopProtocol,
});

These differences are observation points, not automatic root causes. Reused connections can make some timestamps equal. A service worker, cache, redirect, or proxy can also change their meaning. Validate the hypothesis with the browser network panel, server-side tracing, and a performance trace instead of blaming the database whenever TTFB is high.

Strong Sample Answer

“I’ll define a cold baseline: a new top-level HTTPS navigation with no service worker response, HTTP cache hit, or reusable connection, ending in a 200 HTML response.

The browser parses https://shop.example/products?id=42#reviews into the HTTPS scheme, host, default port 443, path, query, and fragment. The fragment stays client-side, so the request target is /products?id=42. The browser or OS then uses a DNS cache or asks a recursive resolver. The resolver also caches answers, so root, TLD, and authoritative servers are not necessarily contacted on each navigation.

After obtaining an address, the browser first checks for a reusable connection. HTTP/1.1 or HTTP/2 commonly uses TCP plus TLS and validates the server certificate. HTTP/3 uses QUIC over UDP with TLS 1.3 integrated into the QUIC handshake, so I would not call TCP mandatory for every HTTPS request. Once connected, the browser sends a GET with the path and query but no fragment. A CDN, load balancer, and application may handle it, or a server may answer directly, returning status, response fields, and HTML.

The browser checks the response type and security policy, selects a renderer, and commits the navigation. The renderer incrementally parses HTML into the DOM and discovers CSS, JavaScript, fonts, and images. Those resources can reuse connections or caches. The DOM and CSSOM feed the render tree, followed by layout, paint, and compositing. First visibility can happen before all resources finish, and the browser can then apply #reviews as an in-document target.

For a slow page, I would gather evidence by phase: navigation timing for DNS, connect, TTFB, and download; the network panel for protocol, cache, and redirects; and a performance trace for main-thread script, style, layout, and paint. That separates name resolution, network and server time, and browser rendering instead of reciting a fixed pipeline.”

Common Mistakes

• Treating one fixed sequence as every real path → caches, service workers, and reused connections skip network work → state a cold baseline and then name the conditions that shorten it.
• Claiming HTTPS always starts with TCP → HTTP/3 uses QUIC over UDP with integrated TLS 1.3 → separate TCP-based HTTP from QUIC-based HTTP.
• Sending #reviews to the server → the HTTP target excludes the fragment → send /products?id=42 and keep the fragment client-side.
• Claiming the browser queries a root DNS server every time → the client, recursive resolver, and delegation chain can all use caches → explain recursion and delegation without inventing a mandatory query sequence.
• Repeating DNS, TCP, and TLS for every subresource → same-origin connections and cached state are often reusable → add work only for a new origin, stale state, or incompatible connection.
• Making a CDN, microservices, cache, and database mandatory → server topology varies → say “may pass through” and expand only for the actual architecture.
• Equating received HTML with a finished page → commit, parse, first paint, DOMContentLoaded, and load are distinct milestones → define the completion point being discussed.
• Naming protocols without diagnosing performance → the answer shows no engineering judgment → map DNS, connect, TTFB, download, and rendering to observable evidence.

Follow-up Questions

Follow-up 1: What changes when a fresh HTTP cache entry or service worker is available?

A fresh cache entry can supply the response without contacting the origin. A stale entry may require a conditional request and a 304 response. A service worker can return its own cached response, forward a fetch, or combine both. Regardless of the source, the browser may still have to commit, parse, and render the document. Specify the cache source and validation state instead of saying “a cache means nothing happens.”

Follow-up 2: How does the HTTP/3 path differ from HTTP/2?

HTTP/2 commonly runs over TLS on TCP. HTTP/3 maps HTTP semantics to QUIC; QUIC runs over UDP and integrates TLS 1.3. Both support concurrent streams on one connection, but transport loss for one HTTP/3 stream does not force unrelated streams to wait for recovery of a single TCP byte stream. If no usable QUIC path is available, the client can use TCP-based HTTP.

Follow-up 3: Which steps repeat if the server returns a 301 to another host?

The browser processes the redirect and Location, parses the new URL, and applies redirect and security policy. If the new host has no usable DNS answer or compatible connection, name resolution and connection establishment are needed again; reusable state can remove those steps. It sends another request until it obtains a final response or hits redirect limits. Under HTTP semantics, a Location without a fragment inherits the original fragment; a Location with its own fragment uses the new one. Neither fragment is included in the HTTP request target.

Follow-up 4: DNS and TTFB are fast, but the page stays blank. What do you inspect first?

The network evidence has already narrowed the search. Confirm that HTML arrived and that content type or security policy did not block required resources. Then inspect the performance trace for long tasks, synchronous scripts, stylesheets, fonts, and expensive layout. Align first paint with the critical-resource waterfall and main-thread timeline to find the first dependency preventing pixels, rather than optimizing DNS again.

Follow-up 5: Why can images still be missing after DOMContentLoaded?

DOMContentLoaded covers document parsing and relevant blocking scripts; it does not wait for every image and other subresource. load is closer to completion of the document and dependent resources, but lazy loading, later script fetches, and continuous updates can still follow. Choose a performance milestone that matches the user-visible goal instead of treating one event as “everything is done.”