What happens when you type a URL into your browser?

This google.com visit uses DNS, establishes a secure connection, sends an HTTP request, then renders the response.

The browser knows google.com as a name, not the network address it needs to contact. It asks a resolver, which looks up that name through DNS; the IP address comes back to the resolver, then to the browser. Here, we’re assuming there’s no usable cached answer, though caching can shorten this path.

The IP address identifies the endpoint the browser will contact. The browser sends SYN, the edge replies with SYN ACK, and the browser finishes with ACK. This three-way handshake establishes TCP state and confirms both sides can communicate. TCP can then provide ordered, reliable delivery, but it doesn’t authenticate google.com or encrypt traffic. TLS handles that.

On the existing TCP connection, the browser starts TLS with a client hello. The Edge returns a certificate, which the browser validates for google.com. They complete the handshake and establish encryption keys. Only then can HTTP messages travel as protected traffic, so TCP reliability and TLS security are separate layers.

The browser sends an HTTP request to the edge over the established TLS connection. GET is the method, asking for a resource; the slash means the root path. The request identifies google.com and includes headers, all protected in transit by TLS.

The Edge checks whether it has a usable cached copy of the requested page. If the content is eligible and cached, it can respond without contacting the Origin. In our assumed cache miss, the Edge forwards the request to the Origin, where the work continues.

Let's think this through. If the edge has no usable cached response, where does it send the request? A: Back to the DNS resolver. B: On to the origin server. C: Straight to the browser renderer. Choose an answer, or just think it through. I'll explain in a moment.

The answer is B: On to the origin server. The edge forwards this cache miss to the origin, which can produce a response. DNS already helped locate an endpoint; it does not create the page. The browser renderer works after response data arrives.

With the assumed cache miss, the edge forwards the browser’s GET request to the origin. The origin handles it and returns an HTTP response to the edge, which passes it back to the browser. The response depends on the request and origin logic; it may not be suitable for caching.

An HTTP response has three parts. The status tells you whether the request succeeded, failed, or should redirect. Headers carry metadata like caching instructions, and the body contains page data when supplied.

The browser parses returned HTML into the DOM, applies styles, then paints the pixels you see. That response may also point to stylesheets, scripts, or images, which can trigger additional requests before the page is fully rendered.

A URL visit is a chain of lookups, handshakes, and exchanges. The pixels on screen come after DNS finds an address, a secure connection is established, and HTTP requests and responses carry the page—and often additional resources—to the browser.