You type leadersloop.com, hit enter, and a page appears in under a second. It feels like one step. It is actually four, a chain of small handshakes between your browser and machines scattered across the world. You don't need to build them, but if you lead anything that runs on the internet, knowing the chain lets you read a status page, question a vendor, and tell a real outage from a shrug.

The quick version

  • The browser is the program that turns a web address into a request and the reply into a page you can see. It does the asking; it doesn't store the site.
  • DNS (the Domain Name System) is the internet's phone book, it turns a human name like leadersloop.com into a numeric address (an IP) the network can actually route to.
  • HTTP is the language the browser and the server speak: a polite request ("please send me this page") and a response ("here it is", or "it moved", or "you can't").
  • Status codes are the three-digit verdict on every response. The first digit is the headline: 2xx worked, 3xx moved, 4xx you got it wrong, 5xx the server got it wrong.

The idea in depth: a four-step relay

Start with the browser, because it is the only part most people ever see. A browser, Chrome, Safari, Firefox, Edge, is a client: a program whose job is to fetch documents from servers and render them. When you enter an address it parses the URL into pieces (the protocol https, the host leadersloop.com, the path /toolkit/), then sets about finding the machine named by that host. It cannot reach leadersloop.com directly, because the network doesn't route by name. It routes by number.

Turning the name into a number is the job of DNS. As Cloudflare's learning centre puts it, DNS is "the phonebook of the Internet," translating human-readable domain names into the IP addresses machines use to find each other ("What is DNS?", Cloudflare Learning). The lookup is a small hierarchy of questions. Your browser asks a recursive resolver (usually run by your ISP, or a public one like Cloudflare's 1.1.1.1). If the answer isn't already cached, the resolver works down a chain: a root server points it to the top-level-domain server for .com, which points it to the authoritative server that actually holds the record for leadersloop.com and returns the IP (Cloudflare, "DNS server types"). Why this earns its keep: when a site is unreachable for some users but fine for you, suspect DNS and caching before you declare the server down. Stale or slow-to-propagate DNS records are behind a lot of "well, it works for me."

flowchart LR
  A(["Your browser
wants leadersloop.com"]) --> B(["Recursive resolver
(ISP / 1.1.1.1)"])
  B -->|"cached? answer now"| A
  B --> C(["Root server
'.com is over there'"])
  C --> D(["TLD server (.com)
'ask their nameserver'"])
  D --> E(["Authoritative server
returns the IP address"])
  E --> B
A DNS lookup: name in, number out, with a cache that short-circuits most of the journey. Leaders Loop

With an IP in hand, the browser opens a connection (over https, an encrypted version of the same conversation) and speaks HTTP, the HyperText Transfer Protocol. HTTP is gloriously simple in shape: the client sends a request naming a method and a path (GET /toolkit/ means "fetch this"; POST means "here is some data, do something with it"), and the server sends a response, a status line, some headers, and usually a body of HTML. The modern specification, RFC 9110, defines this request-and-response semantics and the meaning of every status code (RFC 9110, "HTTP Semantics", IETF, 2022). The browser then reads the returned HTML, fetches whatever extra files it references (styles, images, scripts), and assembles the page. The leader's takeaway: when a vendor says "the API is up," ask what status codes it is returning. "Up" and "returning 500s" can be true at the same moment.

An honest limitation. This four-step picture is the durable mental model, not the full physics. Underneath it sit TCP/IP and the TLS handshake that secures https; HTTP itself now has faster versions (HTTP/2 and HTTP/3) that multiplex many requests over one connection; and a real page load involves dozens of these requests, caches at every layer, and content delivery networks serving copies from nearby cities. The model is right about what happens and in what order; it deliberately hides the performance engineering. Treat it as a map, not the territory.

Reading the verdict: what status codes actually mean

Every HTTP response carries a three-digit status code, and the first digit tells you almost everything. RFC 9110 groups them into five families: 1xx informational (interim, rarely seen), 2xx success, 3xx redirection, 4xx client error, and 5xx server error (RFC 9110 §15; see also MDN's reference list). The single most useful habit you can build is to read that first digit before anything else, because it tells you whose problem it is.

4xx means the caller asked wrong. 5xx means the server answered wrong. Knowing which is which is half of every incident call.

The handful worth memorising: 200 OK, it worked. 301 Moved Permanently, this address has a new home (the redirect that, done right, preserves your SEO when you move a page). 404 Not Found, the server is fine, but there's nothing at that path; this is a client error because the request named something that doesn't exist. 403 Forbidden, it exists, but you're not allowed. 500 Internal Server Error, the server tried and broke. 503 Service Unavailable, the server is up but temporarily can't cope (overloaded or in maintenance). Here is where it pays off. A screen full of 404s after a site relaunch usually means broken links or missing redirects, a content problem you can brief and fix. A screen full of 500s means the application itself is failing, an engineering incident. Same red error to a user; completely different response from you.

flowchart TD
  A(["HTTP response
read the first digit"]) --> B{"Which family?"}
  B -->|"2xx"| C(["Success
200 OK, carry on"])
  B -->|"3xx"| D(["Redirect
301 moved, 302 temporary"])
  B -->|"4xx"| E(["You asked wrong
404 not found, 403 forbidden"])
  B -->|"5xx"| F(["Server broke
500 error, 503 unavailable"])
The first digit assigns blame before you read a word of the error. Leaders Loop

A worked example

Your marketing lead messages at 9 a.m.: "The new pricing page is down, customers are seeing errors." (Illustrative scenario; the numbers below are for teaching, not a real incident.) Instead of forwarding panic to engineering, you walk the chain.

First, browser and DNS: can you reach the rest of the site? The homepage loads fine, so the domain resolves and the server is reachable, this is not a DNS outage taking down everything. The problem is one page. Next, the status code. You open the page and check what the server returns (any browser's developer tools show it, or you ask an engineer for the response code). Two very different worlds open up. If it's a 404, the page was published at the wrong path or an old link points at an address that no longer exists, a content-and-redirects fix, often minutes, no code deploy. If it's a 500, the application is throwing an error rendering that page, a genuine engineering incident that needs a rollback or a fix, and an honest status update to customers.

Say it's a 301 instead, the page redirects, but to the old pricing URL, which was deleted, ending in a 404. Now you've found the real chain: a stale redirect pointing at a dead address. The fix is to repoint the redirect, not to wake the whole engineering team. The point of the example isn't the specific bug; it's that four cheap questions, does the domain resolve, does the rest of the site work, what status code does this page return, and what is it redirecting to, turn "the site is down" into a precise, assignable problem. That precision is the difference between a calm incident and a noisy one.

Frequently asked questions

What's the difference between the internet and the web?

The internet is the global network of connected computers and the plumbing that moves data between them. The web is one thing that runs on that network, the system of linked pages and sites you reach with a browser over HTTP. Email, video calls and app traffic also use the internet but aren't "the web." Loosely: the internet is the roads; the web is one kind of traffic on them.

What actually is an IP address, and why do we need DNS?

An IP address is the numeric label that identifies a machine on the network, the thing routers use to send data to the right place. Names like leadersloop.com exist for humans, because people can't remember numbers and because the number behind a name can change without the name changing. DNS is the lookup service that keeps the two in sync, so you type the name and the network gets the number.

Is HTTPS just HTTP with a padlock?

It's HTTP carried over an encrypted, authenticated connection (TLS). The conversation, requests, responses, status codes, is identical; what changes is that the traffic is scrambled in transit and you have some assurance you're talking to the real server, not an impostor. The padlock in the address bar signals the encryption is in place, not that the site itself is trustworthy or safe.

Why do I sometimes see a page from a site that's "down"?

Caching. Your browser, intermediate networks, and content delivery networks all keep copies of pages and DNS answers for a while. You may be served a stored copy after the origin has failed, or still be pointed at an old server because a DNS change hasn't propagated to you yet. It's also why clearing your cache or trying a different network sometimes "fixes" a problem that was never really yours.

Do I need to know any of this if I'm not technical?

You don't need to write code, but the mental model pays for itself the first time a vendor is vague or a site misbehaves. Knowing that a 4xx is the caller's fault and a 5xx is the server's lets you ask the right question in an incident call. Knowing DNS is a separate layer stops you from blaming the application for what is really a configuration or propagation issue. It makes you a better buyer and a calmer decision-maker.

Related in the Toolkit

This explainer is the foundation under most of the technology Toolkit: once you know a page is a request answered by a server, the natural next questions are what runs in the browser (client-side) versus what runs behind it (server-side), and where all of it physically lives (hosting & cloud architecture).

Where to go next