What Happens When You Open a Website? DNS, TLS, HTTP and the Browser Explained

One tap, one address, and a website appears. Behind that seemingly small action is a remarkable amount of coordination: name resolution, network routing, encryption, requests, responses and finally the browser turning code into pixels. Let's follow the trip without pretending every site loads the same way.

01 — The address bar is not a teleport button

Imagine I open https://www.example.com/ on Cthulhu. The browser first interprets the URL: https is the scheme, www.example.com the host, and / the path. A fragment such as #section stays in the browser; it is not part of an ordinary HTTP request target.

Before anything travels over the internet, the browser might consult its cache, an existing connection, or a service worker. Redirects, HSTS rules and browser policies can change what happens next. The nine steps below are a typical explanatory path, not a capture of a particular session.

02 — DNS turns a name into useful records

Computers need routing information. DNS can provide A and AAAA records mapping a hostname to IPv4 or IPv6 addresses, along with other information. The browser might ask the operating system or a configured resolver; that resolver may already have a cached answer, or query other DNS servers.

A DNS query is not necessarily sent to your ISP in plain text: local caches, DNS over HTTPS or DNS over TLS, VPNs and enterprise configurations all matter. An IP address does not necessarily identify one physical machine either: CDNs, reverse proxies and anycast are common. In our visualization 203.0.113.42 is a reserved documentation address, not the actual address of example.com.

03 — Packets do not know what a webpage looks like

Your computer sends data across a local network, then through routers toward the selected endpoint. Ethernet or Wi-Fi handles the local hop; IP provides addressing across networks. Routers generally forward packets based on destination information; they do not need to understand HTML.

The route can differ from one request to the next. DNS resolution and connections to the website are also separate exchanges: your browser does not normally send its HTTP request through the DNS resolver. A CDN may terminate the connection close to you while fetching content from elsewhere.

https://www.example.com/

04 — TCP or QUIC: two different ways to connect

HTTP/1.1 and HTTP/2 typically use TCP. Before exchanging application data, TCP establishes a connection, commonly illustrated by SYN, SYN-ACK and ACK. TCP provides a reliable ordered byte stream; losses and retransmissions happen below HTTP.

HTTP/3 is different: it uses QUIC over UDP, not TCP. QUIC provides encrypted, multiplexed streams and integrates TLS 1.3 connection establishment. HTTP/3 availability can be learned through prior knowledge, Alt-Svc or HTTPS DNS records, depending on the client. A browser can fall back to TCP-based HTTP when QUIC cannot connect. The switch in our lab lets you see both models without mixing their handshakes.

05 — HTTPS protects the conversation, not every clue

With TCP-based HTTPS, TLS authenticates the server using a certificate chain and negotiates encryption before protected HTTP data is exchanged. On QUIC, TLS 1.3 is integrated into QUIC's handshake rather than layered after a separate TCP setup.

HTTPS protects request paths, message bodies and most headers in transit. But it does not make you anonymous: destination IP addresses remain available for routing, DNS visibility depends on configuration and parts of the TLS handshake may reveal the requested name unless technologies such as ECH are used. The website itself can still see what you send to it.

06 — The browser asks for a resource

A simple navigation corresponds conceptually to GET /. HTTP also carries information such as the host or authority, accepted media types and optional cookies. With HTTP/2 or HTTP/3, requests use binary framing rather than the plain-text syntax of HTTP/1.1; our lab deliberately shows readable summaries.

Servers respond with a status: 200 means success, 301/302 may redirect, 304 validates a cached resource, and 404 means it wasn't found. This exchange is not guaranteed to be a single request: redirects and authentication can introduce more.

07 — The browser assembles the visible page

The response may contain HTML, which the browser parses into the DOM (Document Object Model). CSS becomes a CSSOM; styles, layout and paint turn document structure into visible pixels. JavaScript can modify the DOM, fetch additional data and change what is rendered.

Images, fonts, scripts and stylesheets often require additional HTTP requests. These can run in parallel, come from different hosts and use different cache entries or connections. The page can become usable before every request finishes; there is no universal instant called “the website is fully loaded.”

08 — Who can see what?

Your local network, DNS resolver, internet access provider, intermediaries and destination server have different viewpoints. Encryption usually hides HTTP content from passive network observers, but not necessarily the fact that you connected to a certain IP. A resolver that handles your lookup can know the domain; a website can learn your IP and the information your browser supplies.

That distinction becomes central when we later compare VPNs, proxies and Tor. Those tools move or limit who can observe parts of a connection; they do not magically remove the need to trust infrastructure.

09 — See the stages on your own computer

Open your browser's Developer Tools → Network, enable the protocol column if available, then reload this page. Watch the document request, response status, timings and the CSS/JavaScript requests. The exact labels depend on the browser. A warm cache, a cold cache and an HTTP/3 connection can look noticeably different.

On Linux, getent ahosts www.example.com asks the system to resolve an address, while curl -I https://www.example.com/ inspects response headers (and does send a real network request). Don't confuse those commands with our illustration below: the illustration is entirely local.

Frequently asked questions

Sources and further reading

This guide deliberately simplifies a complex process. These primary references go deeper on protocols and rendering. The animation is not a trace of a real connection.

• MDN: How the web works
• MDN: Critical rendering path
• RFC 9114: HTTP/3
• RFC 9000: QUIC
• RFC 8446: TLS 1.3
• RFC 1034: DNS concepts