What actually happens when you type a URL and hit Enter
Why this is the question it is
"What happens when you type a URL and hit Enter" is one of the most common questions asked in technical interviews, and for good reason — a genuinely complete answer touches DNS, TCP, TLS, HTTP, and rendering, which means it's really five smaller topics wearing one trench coat. Most explanations either skip half of it or drown you in protocol names before explaining what any of them are for. Here's the version that tries to do neither.
Step 1: turning a name into an address
A URL like https://example.com contains a domain name, not a location a computer can actually route packets to — computers need an IP address for that. So the very first thing that happens is a DNS lookup: your computer asks a DNS resolver "what's the IP address for example.com?" That resolver almost never has the answer memorized either; it asks a chain of other DNS servers (root servers, then servers responsible for .com, then the servers example.com itself designates as authoritative) until one of them replies with an actual IP address, something like 93.184.216.34. This entire lookup is usually invisible and fast, partly because DNS answers get cached — by your browser, your operating system, and often your router — so this full chain only really runs the first time, and cached answers are reused until they expire.
Step 2: opening an actual connection
With an IP address in hand, your computer opens a TCP connection to the server at that address, on port 443 for HTTPS (or 80 for plain HTTP). This is the "three-way handshake": your computer sends a SYN packet, the server replies with SYN-ACK, your computer replies with ACK, and only then does either side actually consider the connection open. This handshake exists so both sides can confirm the other is really there and ready, before either one commits to sending real data — it's the network equivalent of "can you hear me?" / "yes, can you hear me?" / "yes" before a phone call actually starts.
Step 3: making the connection private (TLS)
If the URL starts with https://, there's one more step before any actual web content moves: the TLS handshake. This is where your browser and the server agree on an encryption method and exchange the cryptographic keys needed to encrypt everything that follows, and — critically — where your browser checks the server's certificate to confirm it's actually talking to the real example.com and not something impersonating it. This is the padlock icon in the address bar. Skip this step (plain http://) and everything sent afterward, including any password you type into a form on that page, travels in plain text that anyone positioned between you and the server could read.
Step 4: the actual request and response
Only now does the browser send an HTTP request — a plain-text message that says, in effect, "GET me the page at this path, and here's some information about my browser and what I accept." The server processes that request (which might mean reading a static file, or running application code that queries a database and assembles a page on the fly) and sends back an HTTP response: a status code (200 for success, 404 for not found, 500 for a server error, and dozens more), a set of headers describing the response, and — usually — a body containing the actual HTML.
Step 5: turning HTML into what you see
The browser doesn't just display raw HTML text; it parses it into a structured tree (the DOM), and as it encounters references to CSS and JavaScript files and images inside that HTML, it fires off more requests — each one potentially running through its own DNS lookup, TCP handshake, and TLS handshake if it points to a different domain, which is exactly why a page loading resources from six different third-party domains can feel noticeably slower than one that doesn't. Once the CSS is parsed and applied to the DOM, the browser can calculate the actual visual layout and start painting pixels to the screen. JavaScript can run at various points in this process and modify the page further — fetch more data, change what's displayed, attach the event handlers that make buttons and forms actually do something when you interact with them.
Why the "boring" parts are the ones worth understanding
None of these five steps are exotic — DNS, TCP, TLS, and HTTP are decades-old, extremely well-documented protocols, not clever proprietary tricks. That's exactly what makes this question so useful to actually understand rather than memorize: once you know that a slow page load might be a slow DNS lookup, a slow TCP handshake to a server on the other side of the planet, a slow server generating the response, or a slow browser rendering a bloated page, you have five separate, checkable hypotheses instead of one vague feeling that "the internet is being slow today" — and that's the difference between guessing at a fix and actually finding one.