What happens when you type a URL into your browser?

When you type a URL such as https://www.example.com/pricing into your browser and press Enter, the browser first works out whether you typed an address or a search, then looks up the server's IP address using DNS, opens a network connection to that address, secures it with TLS, and sends an HTTP request for the page. The server (often a CDN edge server near you) sends back HTML, and the browser parses it, fetches the CSS, JavaScript, images and fonts it references, and finally paints the page on your screen. All of that usually happens in well under a second.

This is one of the most popular interview questions in web development because it touches almost every layer of the internet. In this article you'll follow a single request from the keyboard to the rendered page, with particular attention to the DNS part, and you'll see commands you can run to measure each stage on a real site.

Step 1: The Browser Interprets What You Typed

Before anything touches the network, the browser has to decide what your input means.

• Is it a URL or a search? If you type example.com/pricing, the browser recognises a host name and path. If you type best pizza near me, it sends the text to your default search engine instead.
• Which scheme? If you didn't type http:// or https://, modern browsers now try HTTPS first and fall back to HTTP only if HTTPS fails, depending on the browser and its settings.
• Is the host name valid? Internationalised names such as café.example are converted to their ASCII "punycode" form (xn--caf-dma.example) because DNS itself works with ASCII labels.

The browser then splits the URL into parts:

Part	Example	Used for
Scheme	https	Which protocol and default port to use (443 for HTTPS)
Host	www.example.com	The name to look up in DNS and send in the TLS handshake
Port	(implied 443)	Which port to connect to
Path	/pricing	Which resource to request from the server
Query	?plan=team	Extra parameters sent to the server
Fragment	#faq	Handled only by the browser, never sent to the server

HSTS and the Internal Redirect

If you previously visited the site over HTTPS and it sent a Strict-Transport-Security header, or if the domain is on the browser's built-in HSTS preload list, the browser will refuse to use plain HTTP for it. Even if you type http://, it rewrites the URL to https:// internally before sending anything. In Chrome's developer tools this appears as a 307 Internal Redirect, which never reaches the network.

Step 2: Check the Caches

The browser tries hard to avoid work it has already done. Before a DNS query is sent, several caches may already hold the answer:

1. The browser's HTTP cache: If the page itself is cached and still fresh, the browser may not need the network at all.
2. The browser's DNS cache: Chrome, Firefox and Safari keep a short-lived cache of host name lookups.
3. An existing connection: If you already have an open HTTP/2 or HTTP/3 connection to the same server, the browser can reuse it and skip DNS, TCP and TLS entirely.
4. The operating system's DNS cache: On Windows the DNS Client service caches answers, on macOS mDNSResponder does, and on many Linux systems systemd-resolved does.
5. The hosts file: Entries in /etc/hosts or C:\Windows\System32\drivers\etc\hosts override DNS.

You can look inside some of these caches. In Firefox, open about:networking#dns to see the browser's DNS cache. In Chrome, chrome://net-internals/#dns lets you clear the host resolver cache. On Windows you can view the OS cache in PowerShell:

Get-DnsClientCache | Where-Object Entry -like "*example.com*"

Entry                     RecordName                Record Status    Section TimeTo Data
                                                    Type                     Live   Length
-----                     ----------                ------ ------    ------- ------ ------
www.example.com           www.example.com           A      Success   Answer     212      4

Step 3: The DNS Lookup

If none of the caches has a usable answer, the operating system's stub resolver sends a DNS query to the recursive resolver your device is configured to use. That's usually your router, which forwards to your ISP's resolver, or a public resolver such as 1.1.1.1 or 8.8.8.8. Some browsers bypass the OS here and send the query themselves using DNS over HTTPS.

The recursive resolver checks its own cache. On a cache miss it walks the DNS hierarchy: it asks a root server where .com is, asks a .com server where example.com is, and asks the authoritative name server for www.example.com. It then caches the answer and returns it to your device.

Modern browsers usually ask for several things at once:

• An A record for the IPv4 address.
• An AAAA record for the IPv6 address.
• Often an HTTPS record, which can tell the browser that the site supports HTTP/3, which IP hints to use, and other connection details before it connects.

You can make the same queries yourself:

dig www.example.com A +noall +answer
dig www.example.com AAAA +noall +answer
dig www.example.com HTTPS +noall +answer

www.example.com.    300   IN  CNAME  www.example.com.cdn.example.net.
www.example.com.cdn.example.net. 60 IN A 203.0.113.80
www.example.com.    300   IN  CNAME  www.example.com.cdn.example.net.
www.example.com.cdn.example.net. 60 IN AAAA 2001:db8:80::1
www.example.com.    300   IN  HTTPS  1 . alpn="h3,h2" ipv4hint=203.0.113.80

Note the CNAME. Many sites point their www name at a CDN host name, and the CDN's own DNS then picks an edge server close to you. This is why two people in different countries can get different IP addresses for the same site.

A cached DNS lookup takes almost no time. An uncached one typically takes tens of milliseconds, and occasionally a few hundred if a distant authoritative server has to be reached.

Step 4: Opening a Connection

With one or more IP addresses in hand, the browser connects to the server.

Choosing IPv4 or IPv6

If the name has both A and AAAA records, browsers use an algorithm called Happy Eyeballs (RFC 8305). They usually try IPv6 first and, if it doesn't connect within a short delay, start an IPv4 attempt in parallel. Whichever succeeds first wins. This avoids long hangs on networks where IPv6 is broken.

TCP or QUIC

For HTTP/1.1 and HTTP/2, the browser opens a TCP connection with the classic three-way handshake:

1. The browser sends SYN.
2. The server replies SYN-ACK.
3. The browser sends ACK.

That costs one round trip. For HTTP/3, the browser uses QUIC over UDP instead, which combines the transport and encryption handshakes and can start faster. A browser learns that a site supports HTTP/3 either from an HTTPS DNS record or from an Alt-Svc header on an earlier response.

Step 5: The TLS Handshake

For an https:// URL, the browser and server negotiate encryption with TLS, which in practice now means TLS 1.3 for most sites. During the handshake:

• The browser sends a ClientHello that includes the host name it wants, using the SNI (Server Name Indication) extension. This lets one IP address serve many sites with different certificates.
• The browser also uses ALPN to say which HTTP versions it supports, such as h2 and http/1.1.
• The server replies with its certificate. The browser checks that the certificate is valid for www.example.com, hasn't expired, and chains up to a trusted certificate authority.
• Both sides agree on keys, and from then on everything is encrypted.

TLS 1.3 completes this in one round trip, and resumed sessions can be even faster. You can inspect a site's handshake from the command line:

openssl s_client -connect www.example.com:443 -servername www.example.com -alpn h2 </dev/null 2>/dev/null | grep -E "Protocol|ALPN|subject=|issuer="

subject=CN=www.example.com
issuer=C=US, O=Example CA, CN=Example TLS RSA CA
ALPN protocol: h2
    Protocol  : TLSv1.3

Step 6: The HTTP Request and Response

Now the browser sends its HTTP request over the encrypted connection. A simplified HTTP/2 request looks like this:

GET /pricing HTTP/2
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html,application/xhtml+xml
Accept-Encoding: gzip, br, zstd
Accept-Language: en-GB,en;q=0.9
Cookie: session=abc123

The request usually reaches a CDN edge server or a load balancer first rather than the application itself. If the edge has a fresh cached copy, it answers immediately. If not, it forwards the request to the origin server, which might be a web server, an application framework, or a serverless function that queries a database and builds the page.

The response comes back with a status code, headers and a body:

HTTP/2 200
content-type: text/html; charset=utf-8
content-encoding: br
cache-control: public, max-age=0, must-revalidate
strict-transport-security: max-age=31536000; includeSubDomains
alt-svc: h3=":443"; ma=86400

Redirects

Sometimes the first response isn't the page but a redirect, such as a 301 from example.com to www.example.com, or from /pricing to /pricing/. Each redirect to a different host can mean another DNS lookup, another connection and another TLS handshake, so chains of redirects noticeably slow down page loads. Aim for a single hop at most.

Step 7: Rendering the Page

Receiving HTML is only the beginning. The browser now:

1. Parses the HTML into a tree of elements called the DOM.
2. Discovers sub-resources such as stylesheets, scripts, images and fonts. Each one on a new host name needs its own DNS lookup and connection, which is why sites use preconnect and dns-prefetch hints for important third-party domains.
3. Parses CSS into the CSSOM and combines it with the DOM to work out what is visible.
4. Runs JavaScript, which may change the page or fetch more data.
5. Lays out every element, working out its size and position.
6. Paints pixels and composites layers onto the screen.

The browser starts showing content before every resource has arrived, which is why you often see text appear before images.

Measuring Each Stage Yourself

curl can report how long each phase took, which is a great way to see where time goes:

curl -o /dev/null -s -w "\
dns:        %{time_namelookup}s\n\
connect:    %{time_connect}s\n\
tls:        %{time_appconnect}s\n\
first byte: %{time_starttransfer}s\n\
total:      %{time_total}s\n" https://www.example.com/

dns:        0.021453s
connect:    0.035120s
tls:        0.061877s
first byte: 0.143302s
total:      0.145918s

The values are cumulative from the start of the request. In this example DNS took about 21 ms, the TCP connection about 14 ms more, TLS about 27 ms more, and the server took roughly 81 ms to start sending the page. Run it twice and you'll usually see the DNS figure drop to nearly zero, because the answer is now cached.

You can also force curl to skip DNS entirely and connect to a specific IP address, which is useful for testing a new server before changing DNS:

curl -sI --resolve www.example.com:443:203.0.113.80 https://www.example.com/

In the browser, the Network tab of developer tools shows the same breakdown for every request under Timing: "DNS Lookup", "Initial connection", "SSL", "Waiting for server response" and "Content Download".

Where DNS Fits in the Bigger Picture

DNS is only one step, but it's the first network step, and everything else waits for it. A slow or failing lookup shows up in a few familiar ways:

Symptom in the browser	Likely cause
DNS_PROBE_FINISHED_NXDOMAIN or "server IP address could not be found"	The name doesn't exist or isn't resolving
A long pause before anything happens	Slow resolver or unreachable authoritative servers
Site loads by IP address but not by name	DNS problem rather than a server problem
Old version of a site after moving hosts	Cached DNS records pointing at the old server

Because browsers reuse connections and cache answers, a well-configured site only pays the DNS cost occasionally. Keeping the number of different host names on a page low, using a fast DNS provider, and setting sensible TTLs all help.

---

FAQ: Typing a URL Into a Browser

---

Conclusion

Typing a URL sets off a precise sequence: the browser interprets the address, checks its caches, resolves the host name through DNS, connects using TCP or QUIC, secures the connection with TLS, sends an HTTP request, and renders whatever comes back, fetching more resources as it goes. Each step builds on the previous one, and DNS sits right at the start.

Understanding this chain makes troubleshooting far easier. If a site won't load, you can ask which step failed: did the name resolve, did the connection open, did the certificate validate, or did the server respond with an error? Tools like dig, curl -w and the browser's Network tab let you check each one in turn.