What actually happens when you type a web address

You type a short address, press Enter, and within a blink a full page appears. It feels instant, but in that moment your device has consulted a worldwide directory, negotiated a private channel with a computer that may be on another continent, and assembled a page from dozens of separate pieces. Let’s slow the film down and watch each frame.

Step 1: Making sense of what you typed

First, the browser decides whether you typed an address or a search. If it looks like a web address, the browser fills in the missing parts. A bare name becomes a full URL with a scheme (usually https://), a host name and a path.

Many browsers also keep a built-in list of sites that must always use encrypted connections. If the site is on that list, or has told your browser so on a previous visit, the browser skips plain HTTP entirely and goes straight to HTTPS.

Step 2: Turning a name into a number

Computers on the internet find each other with IP addresses, which are numbers. Names exist for humans. The Domain Name System (DNS) is the global directory that translates between them.

The browser checks several caches first: its own memory, then the operating system. If nobody remembers the answer, the question goes to a recursive resolver, a server usually run by your network provider or one you have chosen.

If the resolver does not have the answer cached, it walks the hierarchy:

1. It asks a root server, which points it to the servers responsible for the top-level domain, such as .com.
2. It asks those, which point it to the authoritative servers for the specific domain.
3. It asks the authoritative servers, which reply with the actual address.

Each answer carries a time to live, chosen by the domain owner, telling resolvers how long they may reuse it. That is why the second visit to a site usually skips this whole walk.

Step 3: Opening a connection

With an address in hand, the browser opens a connection to the server. Traditionally this uses TCP, which begins with a three-step greeting: one side says hello, the other acknowledges, the first confirms. Now both sides agree on sequence numbers so data can arrive reliably and in order.

Newer versions of HTTP can instead run over QUIC, a protocol built on UDP. QUIC folds the connection setup and the encryption setup together, which saves round trips, and it handles lost packets more gracefully on wobbly mobile networks.

Step 4: The encryption handshake

Before any page data moves, the browser and server perform a TLS handshake. In broad strokes:

• The browser says which encryption methods it supports and sends material for a key exchange.
• The server picks a method, sends its own key-exchange material and presents a certificate.
• The browser checks that the certificate was signed by an authority it trusts and that it matches the site name.
• Both sides combine the exchanged material to derive the same secret keys, without ever sending those keys across the wire.

In current protocol versions, this typically takes a single round trip, and returning visitors can sometimes resume even faster.

The padlock you see afterwards means the channel is private and you are talking to the holder of that site’s certificate. It is a statement about the connection, not about the intentions of whoever runs the site.

Step 5: Asking for the page

Now the browser sends an HTTP request: a method (usually GET), the path, and headers describing things like preferred languages, accepted formats and any cookies for the site.

The server, or a content delivery network sitting close to you, replies with a status code, headers and a body. Headers carry instructions, too: how long the browser may cache the response, which security policies to apply, and how the content is compressed.

Step 6: Building the page

The body is HTML, which is just text. The browser reads it top to bottom and builds the Document Object Model, a tree of every element on the page.

While parsing, it discovers other resources: stylesheets, scripts, fonts and images. A preload scanner looks ahead and starts fetching these early, so the browser does not have to wait for parsing to reach them.

Stylesheets produce a second tree of style rules. The browser combines the two, works out the size and position of every box (layout), fills in the pixels (paint) and stacks the layers together on the screen (compositing).

Scripts can change the tree at any point, which is why well-built sites load them carefully, so they do not hold up that first paint.

Step 7: Doing less next time

The second visit is faster because almost every step has a shortcut. DNS answers are cached. Connections can be reused. Encryption sessions can resume. Files marked as cacheable are served straight from disk.

Why this is worth knowing

Understanding this journey makes a lot of everyday tech feel less mysterious. Slow site? You can now ask which stage is slow. Certificate warning? You know exactly what check failed. And next time a page appears in a blink, you will know just how much teamwork happened in between.