You type an address, press Enter, and a page appears in under a second. What actually happened in that blink? Quite a lot — and once you see the steps, the whole internet starts to make sense.

Think of the journey like sending a letter through a very fast courier service. You write an address on the envelope, the courier figures out where that address physically is, drives there, hands over your request, and races back with a reply. Every website visit follows the same pattern. Let's walk it step by step.

First, what's in a URL?

A URL (Uniform Resource Locator) is the address on the envelope. Each part has a job: 

https://www.coder000.com/post/json-explained-for-beginners
└─┬─┘   └───────┬───────┘└─────────────┬────────────────────┘
scheme       domain                  path
  • Scheme — https says how to talk: HTTP, wrapped in encryption.
  • Domain — www.coder000.com says which server to talk to.
  • Path — /post/json-explained-for-beginners says which page you want from that server.

The journey, step by step

  1. The browser checks its own memory first. Before doing any work, your browser asks: "Have I been here recently? Do I already have a copy?" This is the cache, and it's why a second visit to a site feels faster than the first.
  2. DNS lookup: finding the real address. Computers don't route traffic by names like coder000.com — they use numeric IP addresses. DNS (Domain Name System) is the internet's phone book: you give it a name, it gives you back a number like 203.0.113.7. Our courier just looked up which street the house is on.
  3. TCP connection: knocking on the door. With the address in hand, your browser opens a TCP connection to the server. This starts with a quick three-part exchange called a handshake — roughly "Hello?", "Hello, I hear you!", "Great, I hear you too." Now both sides know the line is open and reliable.
  4. TLS: sealing the envelope. If the URL starts with https, the browser and server agree on encryption keys before anything private is sent. From here on, every message travels in a sealed envelope — anyone watching the network sees only scrambled bytes.
  5. The HTTP request: asking for the page. Finally, the browser sends the actual request. It's surprisingly readable: 
    GET /post/json-explained-for-beginners HTTP/1.1
Host: www.coder000.com
Accept: text/html
    That's it — a polite note saying "please GET me this page."
  6. The server does its work. On the other end, a program receives the request, maybe reads from a database, builds the HTML for the page, and prepares a reply.
  7. The response comes back. The reply starts with a status code — a three-digit summary of how it went. 200 means success, 404 means "no such page," 500 means the server hit an error. Then comes the content: 
    HTTP/1.1 200 OK
Content-Type: text/html

<!DOCTYPE html>
<html>
  ...the page you asked for...
</html>
  8. The browser builds the page. The browser parses the HTML from top to bottom. Every time it finds a stylesheet, script, or image it doesn't have, it sends another request — our courier makes several more quick trips. A single page visit is really dozens of little request–response journeys.
  9. Render. With HTML, CSS, and images in hand, the browser lays everything out and paints it to your screen. JavaScript runs and can keep updating the page from there. Done — and usually all of this took well under a second.

Tip: You can watch this happen! Open your browser's developer tools (usually F12), click the Network tab, and reload any page. Every row is one request — you'll see the status codes, sizes, and timings for real.

Why this mental model matters

Almost every "why is my site broken?" question maps onto one of these steps. Page not loading at all? Suspect DNS or the connection. Padlock warning? That's TLS. Seeing a 404? The journey worked perfectly — the server just doesn't have that path. Slow page? Count the trips in the Network tab.

Note: We simplified a few things — real browsers reuse connections, DNS answers get cached at several layers, and modern HTTP can bundle many requests together. The order of the story, though, is exactly right.

You now know more about what happens behind the address bar than many working developers ever stop to learn — genuinely. Ready for the next stop? That HTTP request–response pattern is exactly how apps talk to each other too: see REST APIs explained with a pizza shop, and peek inside the responses themselves with JSON explained for beginners.