What Happens When You Type a URL?

You press Enter. In milliseconds, the browser parses, connects, encrypts, and starts drawing. This article breaks down what really happens between keystroke and page load, the process behind DNS, TLS, and the first bytes of HTML

Sun Nov 02 2025 • 10 min read

---

You type a URL.

Before your finger leaves Enter, the browser is already at work. It decides if you meant a search or a site, checks its memory, opens a secure line, and starts streaming HTML — all in a blink.

It feels instant. But that single action triggers one of the most complex local operations your computer performs — a silent chain of lookups, handshakes, and rendering that powers the modern web.

Parsing the Input

The address bar looks simple. You type, it reacts. But under that single line of text, the browser is already reasoning.

The moment you start typing, it tries to guess your intent. Is this a search, a shortcut, or a full address? A space usually means search. A dot suggests a domain. Missing https://? It quietly adds it for you.

Next, it looks inward — not outward. Autocomplete pulls from your history, bookmarks, and open tabs, all stored locally. The suggestions you see are built entirely from your device’s memory, not from the web.

When you press Enter, the browser normalizes what you typed: it encodes symbols, fixes slashes, and creates a proper URL object it can work with.

Try it in DevTools:

new URL("vayce.app:443/../tools/./image-compressor", "https://")

You’ll see how even messy input becomes a clean, valid address before any request is made.

By this point, your browser hasn’t touched the network. It’s still local — thinking, preparing, and making sure the next step is worth a round trip.

Cache and Service Worker Checks

Before the browser touches the network, it looks inward.

The goal is simple: avoid unnecessary trips.

It first scans the HTTP cache, a storage of everything your browser has recently downloaded. If it finds a matching resource with a valid freshness header (Cache-Control, ETag, Last-Modified), it can reuse it instantly. No DNS, no handshake, no waiting.

Then comes the service worker, a background script that can intercept requests. If the site has one installed, it might serve a cached page immediately, fall back to the network, or even combine the two for speed.

If neither cache nor service worker has what’s needed, the browser has no choice but to go online.

You can see this in action: open DevTools → Network, enable Offline, and reload a PWA. If it still loads, that’s the service worker taking over.

But it doesn’t go far just yet. Before asking the internet, it asks itself one more question:

Do I already know where this site lives?

That’s where DNS resolution begins.

DNS Resolution

The browser knows what you want — vayce.app — but it doesn’t yet know where it is.

Every website lives on a server with a number called an IP address — a digital street address that looks something like 104.21.89.50. The web uses DNS, short for Domain Name System, to translate names into those numbers.

But before asking the internet, the browser looks locally. There are several places it might already have the answer:

• Browser cache: a short-term memory of sites you’ve just visited.
• Operating system cache: a deeper list your computer keeps between reboots.
• Router cache: even your Wi‑Fi router remembers recent lookups.

If any of these contain the record for vayce.app, resolution is instant — no network call at all.

If not, the browser asks an external DNS resolver. That might belong to your internet provider, or a public service like Google (8.8.8.8) or Cloudflare (1.1.1.1). The resolver checks the global DNS network to find the correct IP address for the site.

Modern browsers often use DNS over HTTPS (DoH) which is an encrypted way to look up names. It hides your requests from middlemen like ISPs and ensures privacy even on public Wi‑Fi.

Once the resolver replies, the browser stores that result in its local cache. Now it knows exactly which server to contact next.

Often that address points to a Content Delivery Network (CDN) — a global system that sends you to the nearest available copy of the site. So vayce.app in Europe might connect to a server in Frankfurt, while someone in Canada hits one in Montreal.

At this stage, the browser finally knows the destination. The next step is to open a secure line and start talking.

Handshakes and Encryption

The browser now knows where the site lives — time to connect.

Make Contact (TCP)

Before any data moves, your browser sets up a reliable line using TCP — Transmission Control Protocol.

Think of the internet as a noisy mailroom. Data travels in small packets that can arrive late, out of order, or not at all. TCP fixes that by numbering each packet, confirming delivery, and automatically resending anything that gets lost.

The setup begins with a simple three-step greeting:

1. The browser says “SYN” — let’s connect.
2. The server replies “SYN-ACK” — got it, ready.
3. The browser answers “ACK” — confirmed.

This three-way handshake ensures both sides are synchronized and ready to exchange data reliably.

Secure the Line (TLS)

Next comes TLS — Transport Layer Security, which turns that open channel into an encrypted tunnel. This is the TLS handshake, a quick identity check and key exchange:

1. The browser says hello and lists the encryption methods it supports.
2. The server replies with a certificate, proving it’s legitimate.
3. Both sides generate secret keys to lock every future message.

When this completes, the connection is private and verified — the moment you see the padlock icon in your address bar.

Make It Fast

Modern browsers optimize this entire process. Session resumption reuses past handshakes, and HTTP/3 (built on a faster protocol called QUIC) replaces TCP entirely for quicker setup. Fewer round trips, same security.

When the handshakes finish, your browser has a secure, reliable tunnel — ready to send its first real message: the request for the web page.

Sending the Request

With a secure connection open, the browser is ready to speak.

The first real message is an HTTP request — a short, structured note that tells the server exactly what the browser wants. It looks something like this:

GET / HTTP/2
Host: vayce.app
User-Agent: Mozilla/5.0 ...
Accept: text/html,application/xhtml+xml;q=0.9
Accept-Encoding: gzip, br

GET means “retrieve.” The path / asks for the site’s homepage. The other lines describe what formats the browser can read and what compression it supports.

A few things happen behind the scenes:

• Compression negotiation: The browser tells the server it can handle compressed responses (gzip, br), saving bandwidth.
• Language preferences: Accept-Language lists the user’s preferred languages, helping the server choose the right version.
• Cookies and credentials: If you’ve logged in before, small data files (cookies) may travel with the request for session continuity.

All of this fits into a tiny packet — usually less than 1 KB. Yet that small message starts the chain reaction that loads the page.

Once sent, the browser waits quietly, counting milliseconds until the first byte of response arrives. It’s the web’s simplest exchange: I’d like this page, please.

The Server Responds

On the other side of that secure tunnel, the server gets your message — GET / — please send the homepage.

It reads the headers, checks permissions, and starts preparing a reply. Sometimes that means pulling a static HTML file from disk; other times, it runs code, queries databases, and assembles the page dynamically.

When it’s ready, the server sends back an HTTP response:

HTTP/2 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: max-age=0, must-revalidate
Content-Encoding: br

The first line — status code 200 OK — means success. Other codes tell different stories: 301 for redirects, 404 for not found, 500 for errors.

Each line that follows is a header, small metadata describing the body: what type of content it holds, how it’s encoded, and whether it can be cached.

Then comes the body — usually HTML, but sometimes JSON, XML, or even binary data. The browser doesn’t wait for it all to arrive before acting. HTML is streamed, so parsing begins as soon as the first bytes land.

That’s why even slow pages often show something quickly: browsers render as they receive.

As the stream continues, the browser starts building the page structure — one tag, one token at a time — setting the stage for the next phase: parsing.

Rendering the Page

As the first chunks of HTML arrive, the browser begins to build the page — not wait for it.

It reads tags, creates nodes, and starts forming the DOM (Document Object Model). Meanwhile, a background process called the preload scanner looks ahead for resources: CSS, scripts, fonts, and images. They start downloading before the parser even finishes reading the opening tags.

But this stage — rendering — is far more than parsing. It’s how the browser transforms structure and style into pixels. HTML becomes a tree. CSS turns into another. Together, they form the Render Tree, which defines what you actually see.

From there, the browser calculates layout, paints each layer, and hands the result to the GPU for compositing. Every scroll, animation, and fade that follows happens through that same pipeline.

That full process — from stream to layout to paint — deserves its own focus.

Read the detailed breakdown in What Happens When You Load a Page — a closer look at how browsers build, style, and paint everything you see..

Caching and Storage for Repeat Visits

The first visit is the slowest one. Every request, handshake, and download has to happen from scratch. But after that, the browser remembers.

When you return to a site, it reuses pieces of the previous session:

• DNS and TLS sessions are kept alive for a short time, so the browser can reconnect without starting over.
• HTTP caching stores copies of files — CSS, JS, images — along with freshness rules defined by headers like Cache-Control or ETag. If nothing changed, the browser loads them instantly or validates them with a tiny “still valid?” request.
• Service workers extend that memory. They can pre-cache pages, respond offline, or assemble content from both cache and network.

Together, these systems make repeat visits feel local. What was once a network round trip now comes straight from your disk or memory.

Watching It Yourself

You don’t need to guess what the browser is doing — you can watch it.

Open any site (try vayce.app), then open DevTools → Network and click Reload.

You’ll see a timeline appear: each bar a separate request, each color a different phase — DNS lookup, TLS handshake, waiting for response, content download.

Hover over any request and switch to the Timing tab. You’ll find the full breakdown — how long DNS took, when SSL finished, and how quickly the server replied. This view is your real-world map of the process we’ve described.

Want to go deeper? Switch to the Performance tab, click Record, and reload again. You’ll capture everything — from parsing and scripting to painting and compositing — in millisecond detail.

The same systems that make a site feel instant are right there, measurable and visible, hidden in plain sight inside your browser.

Final Thoughts

Every time you load a page, a precise sequence of systems works together — DNS, caching, secure connections, parsing, and layout — all designed to make the web feel instant.

Most of this work goes unnoticed. But once you understand it, you start building differently. You trust the browser’s pipelines, use caching properly, and avoid fighting its concurrency.

The browser remains the most advanced runtime on your computer — and everything you build with it benefits from the same quiet efficiency.