What Happens When You Type a URL in the Browser? Part 1: From URL to HTTP Response

You type an address, press Enter, and wait for a page to appear. By the time the application’s JavaScript runs, the browser has already made several decisions: what to request, whether it needs the network, and how to reach the server securely.

That work can explain why a page feels slow before a single component renders, or why one visitor sees a new deployment while another still sees yesterday’s version.

This article opens the Browser and Web Platform series with the journey from a URL to an HTTP response. We will follow the request for an HTML document, connecting DNS, TLS, HTTP, caching, and CDNs to the delays you can inspect in DevTools. Turning that HTML into pixels is the next article’s subject.

The browser does not repeat every step on every visit. Cached responses, existing connections, and work started ahead of time can shorten the journey.

NETWORK EXPLORER

Inside a navigation

example.com/productsHTTPS

Scenario

01Browser

https://example.com/products

The bar accepts addresses and searches. Here, the input is an explicit HTTPS URL, even with no previous visit. The browser identifies scheme, host, and path; the fragment stays on the client.

Explore a step or press play. HTTPS model with HTTP/2 and a CDN, without redirects or a service worker. Animations do not represent real timings.

Before the network: address or search?

The address bar is also a search field. When you type something and press Enter, you may be choosing an address, a history suggestion, or a search. The browser interprets the input; rules and suggestions vary across browsers and settings. Recognizing an address does not require having visited the site before.

An input such as “how DNS works” usually becomes a search with the configured search engine. In that case, the browser navigates to that service’s search URL. An explicit address such as https://example.com/products?id=123#reviews instead points to a navigation to that host. If you omit the scheme, the browser must choose one according to its policies and settings.

We will follow that HTTPS address with no stored HTTP response, open connection, or usable cached DNS information. This is a teaching example of starting from scratch: in practice, even your first visit may benefit from a shared resolver’s cache or a CDN. The computer already has network connectivity; setting up Wi-Fi and obtaining that connectivity are outside this journey.

What the address tells the browser

With the destination chosen, the browser parses the URL’s parts. Explore the example:

URLOne address, five parts

HTTPS means HTTP protected by TLS. The browser needs a secure connection to access this address.

HTTP request target

GET /products?id=123

Stays in the browser

#reviews

Originhttps://example.com:443

Select a part to explore its role. Port 443 is implicit in HTTPS.

The server decides how to interpret the path and parameters; they do not have to correspond to a file on disk. The fragment stays in the browser: it can scroll to an element or be used by the application, but it is not sent in the HTTP request target.

For an HTTPS URL, the browser also derives an origin from the scheme, hostname, and port. Here, the origin is https://example.com, with the default HTTPS port of 443. Specifying that port explicitly gives the same origin; switching to HTTP, using a subdomain, or choosing port 8443 gives a different one.

This distinction matters because browser security uses origins as boundaries. For example, the same-origin policy restricts how a script can access another origin’s resources. Two addresses can belong to the same company and still be different origins.

The browser may already have a usable response in its HTTP cache. Depending on the caching rules, it can reuse that response immediately or ask the server whether the stored version is still current. In the second case, caching saves a download, but not the network round trip.

A service worker introduces another possibility. If the site has an active service worker whose scope covers this navigation, its code can handle the request and return a stored response, use the network, or combine both approaches. On a genuine first visit, that worker will not yet be installed to handle the initial navigation.

Service workers often use the Cache API to store request-response pairs. That storage is separate from the HTTP cache: application code manages its entries, and they do not automatically expire according to HTTP caching headers. This distinction is useful when a site keeps serving old content even after its HTTP cache settings have changed.

There is also the back-forward cache, or bfcache. It can preserve a whole page, including its JavaScript state, for restoration when you go backward or forward in history. It serves a different purpose from caching responses and is not the mechanism for an ordinary new address-bar navigation.

For the rest of the example, assume the browser needs to fetch the document over the network.

Finding a server with DNS

To open a new connection to example.com, the browser needs an IP address. DNS, the Domain Name System, provides records that can lead to one or more IPv4 or IPv6 addresses.

The answer may already be cached by the browser, the operating system, or a recursive resolver. That resolver is the service that performs DNS lookups on the client’s behalf. Depending on the configuration, the browser may reach it through the operating system or contact it directly, for example using DNS over HTTPS.

Without the necessary cached information, the resolver queries the DNS hierarchy, starting with root servers whose addresses it already knows from its configuration. Here is who takes part in each exchange:

DNSHow the browser finds the IP

The browser talks to the resolver. The resolver asks the other servers until it finds the address.

Browser

What is the IP address of example.com?

Resolver

I’ll look it up for you.

The browser asks the resolver for example.com’s IP address. The resolver performs the following lookups on the browser’s behalf.

1 / 5

Example without caches. 192.0.2.10 is illustrative, not example.com’s real address. Aliases may require further queries.

If the name does not exist or resolution fails, the browser will have no address for this connection and may display an error. With the addresses available, it can attempt a connection. The destination may also be a CDN rather than the machine running the application.

DNS becomes especially relevant when a page relies on many external hosts. Fonts, analytics, images, and widgets can each introduce more connection work. A DNS-prefetch hint can ask the browser to resolve a name early; a preconnect hint can also prepare a connection. These hints help with upcoming requests discovered during a page load, not retroactively with the navigation that delivered the HTML containing them.

Opening a secure connection

If a suitable connection already exists, the browser can reuse it. Otherwise, it needs to establish one. The steps depend on the HTTP version.

For HTTPS over HTTP/1.1 or HTTP/2, the browser opens a TCP connection, typically through a three-way handshake: the client sends SYN, the server answers with SYN/ACK, and the client acknowledges it. TCP provides reliable, ordered delivery of bytes.

TLS then secures that connection. In a typical full handshake, the browser checks the server’s certificate against the requested hostname and a trusted certificate chain. Client and server establish cryptographic keys to encrypt traffic and detect tampering. Certificate authentication is what lets the browser verify whom it is talking to; encryption alone would not establish that identity.

HTTP/3 takes a different route. It runs over QUIC, which uses UDP and integrates TLS 1.3 into connection establishment. QUIC supplies the reliable streams HTTP needs, so using UDP does not make HTTP/3 an unreliable delivery mechanism.

The practical cost is latency: a new connection involves exchanges across the network before the response can arrive. Reuse avoids repeated setup, and HTTP/2 and HTTP/3 can carry multiple request-response exchanges concurrently on one connection.

Asking for the document

With a connection available, the browser can request our page. An abbreviated HTTP/1.1 request looks like this:

GET /products?id=123 HTTP/1.1
Host: example.com
Accept: text/html
Accept-Language: en-US
Accept-Encoding: gzip, br

The first line asks for the resource using GET. Notice that the path and query are present, but #reviews is absent.

The headers describe the request in more detail. Accept indicates acceptable media types, Accept-Language communicates language preferences, and Accept-Encoding advertises supported compression formats. The browser may also include cookies when their attributes and its cookie policies allow it.

HTTP/2 and HTTP/3 use binary framing and pseudo-headers such as :method and :path instead of this textual request line. The underlying HTTP meaning remains the same.

The destination might respond with a redirect and a Location header. In that case, the browser follows the new URL, possibly needing another DNS lookup or connection. Even a redirect that reuses a connection adds another request before the final document can arrive.

Where the response comes from

Our request has left the browser, but it may be served before reaching the application. Many sites put a content delivery network, or CDN, in front of their servers. A request reaches an edge server, ideally close to the user in network terms. If that server can serve a cached response, it can answer without fetching the document from the origin server.

The CDN cache lives in the site’s infrastructure, separate from the browser’s local cache. In this example, a cache hit means the edge has a response it can reuse; a cache miss means it needs to fetch one from the origin. Compare the two routes:

CDNHow far does the request travel?

Cache hit Response at the edgeCache miss Fetch from origin

GET/products?id=123HTML document

BrowserCDN edgeOrigin

Switch scenarios to compare the route. Illustrative animation, not real timings.

Here, origin server means the upstream server responsible for the content. It is a different use of “origin” from the browser security concept we discussed earlier.

If the edge needs an upstream response, the origin server might read a file, render HTML, query a database, or call another service. All of that can contribute to the wait. Static assets are common candidates for CDN caching; HTML can also be cached when its personalization and freshness requirements allow it.

This is where time to first byte, or TTFB, becomes useful. For a navigation, it measures the wait from the navigation’s start until the response begins arriving. That interval can include redirects, DNS, connection setup, and server work. It does not isolate the application’s processing time.

A high TTFB tells you where to investigate. It cannot, on its own, tell you whether the cause is a distant server, a cache miss, or a slow database query.

Reading the response

The response carries a status code, headers, and, when applicable, a body. For our page, the body is HTML. Here are some possible response headers, shown in HTTP/1.1 form:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: no-cache
ETag: "products-v42"
Content-Encoding: br

The status indicates that the request succeeded. Content-Type identifies HTML encoded as UTF-8. Content-Encoding says the transferred body uses Brotli compression, which the browser decodes before parsing the HTML.

The caching fields explain what a later visit can do. no-cache permits storage but requires validation before reuse; no-store tells caches not to store the response. The ETag is a validator. On a later request, the browser can send it in an If-None-Match header. If the representation is unchanged, a 304 Not Modified response lets it reuse the stored body without downloading that body again.

Other headers can affect the page beyond this download. Set-Cookie asks the browser to store a cookie, subject to its policies. Content-Security-Policy can restrict which scripts and other resources the page may load. These instructions help explain why receiving HTML successfully does not guarantee that everything on the page will work.

The browser can start parsing HTML as it arrives. It does not need to wait for the entire response before discovering stylesheets, scripts, and images and requesting them. Downloading and rendering therefore overlap: the browser can work on the page while more of the document is still arriving.

Following the journey in DevTools

To observe the process in Chrome, open DevTools before navigating and select the Network panel. Enable Preserve log if you want to keep redirects visible across navigations, then load the page and select its main document request.

Start with three places:

Headers shows the URL, status, and request and response headers. Look for redirects, content type, and caching instructions.
Timing breaks down the request into phases such as DNS lookup, connection setup, waiting, and download. Missing phases may reflect cached DNS information or connection reuse.
The Protocol and Size columns help identify the HTTP version and whether the response came from a local cache. You can enable Protocol from the column header menu.

NETWORK / TIMINGWhere the time goes

StartElapsed time

DNSFind the IP
ConnectionTCP + TLS
SendRequest sent
WaitingWaiting (TTFB)
DownloadReceive the body

Schematic of a new HTTPS connection over TCP, not to scale. Waiting includes network and server processing. Queuing and other phases are omitted.

Compare a visit with a reload. For a test without the browser’s HTTP cache, select Disable cache while DevTools remains open. This does not clear DNS caches, guarantee a new connection, bypass a CDN cache, or disable service-worker responses. To bypass a service worker in Chrome, use Application > Service Workers > Bypass for network.

You can also inspect the current document’s navigation timing in the Console after the page has loaded:

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

if (navigation) {
  console.table({
    dnsMs: navigation.domainLookupEnd - navigation.domainLookupStart,
    connectionMs: navigation.connectEnd - navigation.connectStart,
    navigationTtfbMs: navigation.responseStart - navigation.startTime,
    requestToFirstByteMs: navigation.responseStart - navigation.requestStart,
    downloadMs: navigation.responseEnd - navigation.responseStart,
  });
}

These values are in milliseconds. The connection interval includes secure connection setup when applicable. The navigation TTFB spans more than the request-to-first-byte interval, so do not add these rows together. Zeros can indicate skipped or reused steps, and browser privacy restrictions can limit timing detail.

In the Network panel, Waiting (TTFB) refers to waiting for the response after the request is sent. It is narrower than the navigation-level TTFB above. Keeping those starting points straight avoids mistaking all the waiting time for server processing.

Once you can locate the delay, you can choose a relevant fix: removing a redirect, changing a cache policy, or investigating the server. The next article, From HTML to Pixels: DOM, CSSOM and the Render Tree, follows the HTML into the browser: how it builds the document and style structures, combines them, and calculates the layout that prepares the page for painting.