What happens when you type a URL into your browser?

After Enter on google.com, the browser looks up an address, secures or reuses a connection, requests the page, and assembles it.

For google.com, the browser needs an IP address before it can contact the destination. It asks DNS to resolve the name, and DNS returns an address; that address can vary by location or time. If a usable answer is already cached, the browser may skip a fresh lookup.

The browser has an address for the selected endpoint, but it still needs a transport connection. It sends SYN; the endpoint replies with SYN ACK; then the browser sends ACK. That three-message handshake establishes TCP, not a page request. TLS can begin after this, unless a suitable existing connection is reused.

The browser starts TLS with the endpoint, which sends a certificate. The browser checks that the certificate is valid for google.com, helping confirm it’s talking to the intended site. Both sides establish encryption keys, then finish the handshake. After that, HTTP data is protected in transit; a reused secure session can make setup shorter.

With the secure connection ready, the browser sends GET / to the endpoint. GET requests the site’s root path, and Host: google.com identifies which website the request is for. DNS found the endpoint’s address; it didn’t choose the page. The endpoint then sends an HTTP response back to the browser.

For google.com, the Browser sends its request to an Edge endpoint. The Edge can answer there or contact the Origin if it needs content; finding the address and securing the connection got the request to this entry point, but the page still has to be supplied and assembled.

Let's think this through. If the browser has an address but has not sent an HTTP request, what can it know about the page? A: The server address, but not the page content. B: The complete HTML and images. C: The final rendered layout. Choose an answer, or just think it through. I'll explain in a moment.

The answer is A: The server address, but not the page content. DNS helps locate an endpoint; it does not deliver the page. The browser still needs a connection and an HTTP response before it can assemble what you see.

The browser sends GET / to the edge. In this illustrative path, the edge fetches the page from the origin, then returns an HTTP response. That response has a status, headers, and a body: the status reports the outcome, headers carry metadata, and the body contains content. Sometimes the edge can respond without fetching from the origin.

A CDN isn't one server that answers every request. The browser contacts an edge, which checks its cache; cacheable content may be served nearby. If it isn't available there, or needs origin handling, the edge contacts the origin. Google's main HTML isn't guaranteed to come from cache.

The response body is a starting point, not a finished page. The browser parses its HTML, discovers needed images, styles, and scripts—often making more requests—then uses those pieces to render what you see.

For web navigation, finding an endpoint, communicating securely, requesting resources, and rendering them are distinct jobs. Caches and reused connections can skip or shorten steps. An edge-or-origin response, plus needed resources, becomes the page you see.