What Happens When You Type a URL and Press Enter

The Short Version

Between typing a web address and seeing a page load, a browser performs several distinct steps in well under a second: find the server, connect to it, secure the connection, request the page, and render what comes back. Each step is invisible in normal browsing, but understanding them makes it much easier to reason about why a site is slow, why a change isn't showing up, or where a request is actually failing.

Step 1: Parsing the URL

The browser first breaks the URL into its parts: the protocol (https://), the domain (register.rw), and the path (/blog/what-happens-when-you-type-a-url). Only the domain matters for the next step; everything else waits until a connection exists.

Step 2: The DNS Lookup

The browser needs an IP addressThe numeric address (like 203.0.113.10) that identifies a server on the internet. before it can contact anything, so it performs a DNSThe Domain Name System — the internet's directory that translates domain names into the IP addresses of servers. lookup: checking its own cacheA temporary store of already-fetched data, kept so it can be reused quickly instead of fetched again. first, then asking a resolverA DNS server, usually run by your ISP, that looks up domain names on your behalf and caches the answers., which in turn may query a root serverOne of the DNS servers at the top of the hierarchy that direct a lookup toward the right top-level-domain servers., a TLDTop-Level Domain — the last part of a domain name, such as .com or .rw. server, and finally your domain's own nameserversA DNS server that holds the authoritative records for a domain and answers where its website and email live. to get the current answer. See How Domains Work for the mechanics of this lookup in full, and Root Servers and TLD Servers for what sits above your domain's own nameservers in that chain.

Step 3: Establishing a TCP Connection

With an IP address in hand, the browser opens a TCPTransmission Control Protocol — the method that reliably delivers data between two computers on the internet. connection to the server, a short back-and-forth handshake that confirms both sides are ready to exchange data reliably before any actual content is requested. This happens for every connection, regardless of what's being requested.

Step 4: The TLS Handshake (for HTTPS)

If the site uses HTTPSHTTP secured with encryption (TLS), so data between the browser and server can't be read or tampered with in transit., which is effectively every modern website, the browser and server perform a TLSTransport Layer Security — the encryption that protects data in transit and powers HTTPS (the successor to SSL). handshake next: exchanging the site's SSLThe certificate technology behind HTTPS. Modern 'SSL' is really TLS, but the name stuck. certificate and agreeing on an encryption key for the rest of the sessionA way for a site to remember a specific visitor across multiple requests, usually backed by a cookie.. See SSL Certificates Explained for what this certificate actually does and why browsers flag sites that skip this step.

Step 5: Sending the HTTP Request

Only now does the browser send the actual HTTPHyperText Transfer Protocol — the rules browsers and servers use to request and send web pages. request, specifying the exact path it wants (/blog/...), along with headers describing the browser, accepted content types, and any cookiesA small piece of data a site stores in your browser to remember things like your login between requests. already stored for that domain. See Cookies and Sessions Explained for what those cookie headers are actually doing.

Step 6: The Server Responds

The server processes the request and sends back a response, starting with a status code that tells the browser what happened: success, redirectA server instruction that automatically sends a browser from one URL to another., or an error. See HTTP Status Codes Explained for what each of those codes actually means.

Step 7: Rendering the Page

Once the browser has the response, it parses the HTML, requests any additional files it references (images, stylesheets, scripts, each repeating a version of steps 2 through 6), and progressively renders the page. This is usually the slowest visible step from a visitor's perspective, even though it happens after every network step above it has already completed.

Why This Matters for Website Owners

Knowing this sequence makes troubleshooting far more precise: a page that's slow to start loading points at DNS or the server itself; a page that loads unencrypted points at a missing or misconfigured SSL certificate; a page that never appears at all is often a DNS or hosting issue rather than anything about the page's own code. Most performance and connectivity problems trace back to one specific step in this chain, not the process as a whole.