# HTTP, Explained - the language the web speaks

> What HTTP actually is: every time you load a page, your browser sends a request and a server sends a response. This guide makes that conversation - methods, status codes, headers, cookies, and the S in HTTPS - finally make sense.


---

# HTTP, Explained

Every time you open a website, two computers have a short, polite conversation: your browser asks for something, a server hands it back. That conversation is HTTP - the language the web speaks. You've relied on it every day without ever being shown how it works, and that's fine until a page returns `404`, a developer mentions a "POST request," or `https://` turns red and you wonder if you're about to be robbed.

This guide is the manual nobody handed you. By the end you'll picture exactly what your browser and a server are saying to each other, read a status code without panic, and understand what that little padlock is actually protecting. No deep networking background needed - we start from the conversation and build up.

## How to read this
- **Want a specific answer right now?** Phase 2 has the status-code table - if you just want to know
  what `404` or `500` means, jump to [Phase 2: Methods & Status Codes](02-methods-and-status-codes.md).
- **Want it to finally make sense?** Read in order. Each phase builds on the last: the conversation
  first, then the words it uses, then the details that ride along.

## The phases
1. **[Request & Response](01-request-and-response.md)** - the core model: your browser sends a
   request, the server sends a response. Plus the anatomy of a URL, the address you're really typing.
2. **[Methods & Status Codes](02-methods-and-status-codes.md)** - the verbs (GET, POST, PUT, DELETE)
   and the three-digit replies (2xx, 3xx, 4xx, 5xx), with a table and how to read a code calmly.
3. **[Headers, Cookies & the S in HTTPS](03-headers-cookies-and-https.md)** - the extra notes each
   message carries, how sites remember you, and what encryption actually buys you.

> This guide stops at the everyday mental model. The deeper machinery - how packets actually travel,
> ports, DNS, and the layers underneath HTTP - lives in its own guides:
> [How the Internet Works](/guides/how-the-internet-works),
> [IP, DNS, and Ports](/guides/ip-dns-and-ports), and [The TCP/IP Model](/guides/tcp-ip-model).
> APIs are built directly on top of HTTP, so a future guide on what an API is will link back here.


---

# Request & Response - the core model

Here's the secret that makes all of HTTP click: it's one move, repeated forever. One side asks; the other answers. Your browser sends a **request**, and a server sends back a **response**. Every page you've ever loaded, every image, every login - all of it is this same back-and-forth, happening faster than you can see. Once you can picture that one exchange, nothing else in this guide is mysterious.

## The two roles: client and server

A **client** is whoever starts the conversation - almost always your web browser, but it could be a phone app or a script. A **server** is the computer sitting there waiting to answer. The client speaks first, always. The server never randomly calls you up; it only ever replies to something asked.

📝 **Terminology.** **Client** = the side that asks (your browser). **Server** = the side that answers (the machine hosting the website). The whole pattern is **request–response**.

It's tempting to imagine the website "sending you" a page out of the blue, like a TV channel broadcasting. It doesn't work that way - nothing arrives until your browser asks for it. When a page seems to update on its own, your browser is quietly sending more requests in the background - still the same one move.

```mermaid
sequenceDiagram
  participant Client as Client (your browser)
  participant Server as Server (example.com)
  Client->>Server: request: GET me the page at /about, please
  Note right of Server: looks it up
  Server-->>Client: response: 200 OK - here's the HTML
```

One arrow out, one arrow back. Hold onto this picture - everything below just fills in what those two arrows actually contain.

## A real request and response

When you visit a page, your browser sends a request that, written out in plain text, looks roughly like this:

```http
GET /about HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Accept: text/html
```
*What just happened:* your browser asked for one specific thing. The first line is the heart of it: `GET` is the **method** (the verb - "fetch me this," covered in [Phase 2](02-methods-and-status-codes.md)), `/about` is the **path** (which page), and `HTTP/1.1` is the version being spoken. The lines below are **headers** - extra notes like `Host` (which site, since one server can host many) and `Accept` (what format the browser wants back). More on headers in [Phase 3](03-headers-cookies-and-https.md); for now, a request is a verb, a path, and some notes.

The server reads that, finds the page, and sends a response:

```http
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1256

<!DOCTYPE html>
<html>
  <head><title>About Us</title></head>
  <body>...</body>
</html>
```
*What just happened:* the server answered. The first line is its verdict: `200 OK` means "found it, here you go" (status codes are all of [Phase 2](02-methods-and-status-codes.md)). Then a couple of headers describing the answer - `Content-Type: text/html` says "what follows is a web page" - a blank line, then the **body**: the actual HTML your browser draws on screen. Request had a verb and a path; response has a status and a body. That symmetry is the whole protocol.

💡 **Key point.** A request is *"verb + address + notes."* A response is *"status + notes + the actual content."* Read those two messages and you can read HTTP.

## The anatomy of a URL

Every request starts with an address - a **URL** - and it's more structured than it looks. Learning to read it is like learning to read a postal address: once you see the parts, you know exactly where a request is headed.

📝 **Terminology.** **URL** stands for Uniform Resource Locator. In everyday speech it's just "the link" or "the web address" - the thing in your browser's address bar.

Take this one apart:

```text
   https://shop.example.com/products/shoes?color=blue&size=10
   └─┬─┘   └──────┬───────┘└─────┬──────┘└────────┬─────────┘
   scheme       host           path             query
```

- **Scheme** (`https`) - *how* to talk. `https` means "HTTP, but encrypted" (the whole point of [Phase 3](03-headers-cookies-and-https.md)); plain `http` means unencrypted. It tells the browser which rules to use before it says a word.
- **Host** (`shop.example.com`) - *who* to talk to, the server's name. Behind the scenes it gets translated into a numeric address so your request can find the machine - that translation is DNS, covered in [IP, DNS, and Ports](/guides/ip-dns-and-ports).
- **Path** (`/products/shoes`) - *which thing* on that server you want. Think of the host as a building and the path as the room number - each path is a different resource the server can hand back.
- **Query** (`?color=blue&size=10`) - *extra instructions* tacked on. It starts with a `?`, and each instruction is a `name=value` pair joined by `&`. Here it says "the shoes page, but filtered to blue, size 10" - a way to carry parameters without changing which path is asked for.

The next time a link looks like a wall of `?utm_source=...&ref=...&id=842`, you won't be intimidated: it's a path, a `?`, and a list of `name=value` instructions. When a developer says "pass it as a query parameter," you'll know exactly which part of the URL they mean.

⚠️ **Gotcha.** The query string is *visible* - it sits in the address bar, your browser history, and often the server's logs. Fine for a search term or a filter, a poor place for anything secret. Putting a password or token in the query (`?password=hunter2`) writes it down in several places you don't control. Secrets travel in headers or the request body instead - both covered in [Phase 3](03-headers-cookies-and-https.md).

## Recap

1. HTTP is one repeated move: the **client** (your browser) sends a **request**, the **server** sends a **response**.
2. A **request** is a verb + a path + some header notes. A **response** is a status + some headers + the body (the actual content).
3. A **URL** breaks into **scheme** (how), **host** (who), **path** (which thing), and **query** (extra `name=value` instructions after a `?`).
4. The query string is visible to many eyes - fine for filters, wrong for secrets.

You now have the skeleton. Next, let's name the verbs a request can use, and learn to read the three-digit replies a server sends back - including the famous `404`.

Watch it animated: [an HTTP request/response](/explainers/HTTPRequest.dc.html)

## See it move

Step through the journey of one request - the DNS lookup, the request out, and the response back:

```playground-network
```


---

# Methods & Status Codes - the verbs and the replies

Phase 1 showed the shape: a request goes out, a response comes back. Now the two most important words in that exchange - the **method** (the verb the client uses to ask) and the **status code** (the three-digit reply the server uses to answer).

These are the parts you'll actually run into by name. A teammate says "make it a POST." A page shows `Error 500`. A tool prints `301`. None of it is cryptic once you know the small set of verbs and the four families of replies.

## Methods - what the client is asking for

A **method** is the verb at the start of a request. It tells the server not just *which* thing you want, but *what to do* with it - read it, create one, replace it, or delete it. Four cover almost everything you'll meet.

📝 **Terminology.** "Method," "HTTP verb," and "request type" all mean the same thing: that first word (`GET`, `POST`, …) in the request.

| Method | What it means | A plain-English example |
|---|---|---|
| `GET` | **Read** - fetch something, change nothing | Loading a page, viewing a profile, running a search |
| `POST` | **Create / submit** - send data to make something new | Submitting a sign-up form, posting a comment |
| `PUT` | **Replace** - overwrite an existing thing with new contents | Saving an edited profile, updating a document |
| `DELETE` | **Remove** - delete a thing | Deleting a photo, removing an account |

The distinction worth burning in: **`GET` only reads; everything else changes something.** Clicking a link or typing an address sends a `GET` - that's why merely *looking* at a page is safe to repeat. Submitting a form is usually a `POST`, because you're asking the server to *do* something that sticks.

Here's a `POST` carrying form data, so you can see how it differs from the `GET` in Phase 1:

```http
POST /comments HTTP/1.1
Host: example.com
Content-Type: application/json

{"article": 42, "text": "Great write-up, thanks!"}
```
*What just happened:* the client asked the server to *create* something. The verb is `POST`, the path `/comments` is where comments live, and unlike a `GET`, this request carries a **body** - the new comment, here as JSON. A `GET` asks "show me"; a `POST` says "here, take this and do something with it."

⚠️ **Gotcha.** Because `GET` is meant to be safe and repeatable, browsers freely retry, cache, and prefetch it. Never wire a `GET` to *do* something with consequences - a link like `/delete?id=42` is a classic mistake, since anything that follows links (a browser, a preview bot, antivirus) might fire it without anyone clicking. Actions that change things belong on `POST`, `PUT`, or `DELETE`.

Once you know these verbs, an API's instructions or your browser's network panel stop being cryptic - you can guess what a request does before anyone explains it. It's also why refreshing a payment page sometimes warns "are you sure you want to resubmit?" - that page was a `POST`.

## Status codes - how the server answers

Every response opens with a three-digit **status code** - the server's one-glance verdict on how the request went. You met `200 OK` in Phase 1. The trick that makes them all readable: **the first digit tells you the whole story.** The other two are just detail.

📝 **Terminology.** A **status code** (or "HTTP status") is that number - `200`, `404`, `500`. The short text beside it (`OK`, `Not Found`) is just a human-friendly label for the same thing.

There are five families. These four are the ones you'll meet daily:

| Family | Meaning | Read it as | Common members |
|---|---|---|---|
| **2xx** | **Success** | "It worked." | `200 OK`, `201 Created` |
| **3xx** | **Redirect** | "It moved - go look over there." | `301 Moved Permanently`, `302 Found` |
| **4xx** | **Client error** | "*Your* request was wrong." | `404 Not Found`, `403 Forbidden`, `401 Unauthorized` |
| **5xx** | **Server error** | "*The server* broke." | `500 Internal Server Error`, `503 Service Unavailable` |

(There's also **1xx**, an "informational, hold on" family you'll almost never see by hand.)

`4xx` and `5xx` cause the most stress, so be clear about the difference - it tells you who can fix it:

- **`4xx` means the problem is on the asking side.** The request was off - wrong address, no permission, not logged in. `404 Not Found` is the famous one: a path that isn't there (typo'd URL, deleted page, dead link). `401` and `403` mean "you're not allowed." The server is fine; the request needs fixing.
- **`5xx` means the problem is on the answering side.** Your request was reasonable, but the server tripped over its own feet - a bug, a crash, an overloaded machine. `500 Internal Server Error` is the generic "something blew up back here." Usually nothing *you* did wrong, and often nothing to do except wait or report it.

Here's a redirect, since `3xx` is the family people understand least:

```http
HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-home
```
*What just happened:* the server didn't send a page - it sent a forwarding address. `301` says "this moved for good," and `Location` says where. Your browser reads that and quietly sends a *second* request to the new URL, so you usually never notice. That's why an old bookmark can still land you on the right page.

💡 **Key point - how to read any code calmly.** Glance at the first digit. `2` = it worked. `3` = it moved. `4` = the request was wrong (check the address, check whether you're logged in). `5` = the server broke, not your fault. You don't need to memorize the rest - the family tells you who's responsible and what to try next.

⚠️ **Gotcha.** A `200 OK` only means *the HTTP exchange* succeeded - the server received the request and sent a response. It does **not** guarantee the response is what you wanted. A buggy site can return `200` with an error message painted inside the page, or an empty result. "I got a 200" means the conversation completed, not that everything is correct - look at the response *body* when something looks wrong despite a `200`.

That habit - *first digit first* - is most of what separates calm debugging from flailing.

## Recap

1. The **method** is the request's verb: `GET` reads (and only reads), while `POST`, `PUT`, and `DELETE` create, replace, and remove.
2. Never put a consequential action behind a `GET` - it can fire without a real click.
3. A **status code**'s first digit is the whole story: **2xx** worked, **3xx** moved, **4xx** your request was wrong, **5xx** the server broke.
4. `4xx` = fix the request (address, login, permission). `5xx` = wait or report it.
5. A `200` means the exchange completed, not that the content is correct - check the body when in doubt.

You can now read both halves of an HTTP exchange. The last phase covers the extras that ride along on every message - the headers, the cookies that let a site remember you, and the encryption behind `https://`.

Build a request and see the raw HTTP that goes over the wire, plus the response it gets back:

```playground-http
```


---

# Headers, Cookies & the S in HTTPS

You've got the core conversation down: request out, response back, verb on one side, status on the other. But we kept waving at some "extra notes" on each message. This phase opens them up.

Those notes are **headers**, and they carry everything that isn't the main content - what format the body is in, who you are, whether the site is allowed to remember you. Out of headers come **cookies** (how a site knows it's still you on the next click) and a lot of what makes **HTTPS** trustworthy.

## Headers - the notes on every message

A **header** is a single `Name: Value` line attached to a request or response, carrying information *about* the message rather than the message itself. You saw a few in Phase 1: `Host`, `Content-Type`, `Content-Length`. There can be many, and both sides use them.

Think of mailing a package: the body is what's *inside* the box, headers are everything written *on* it - who it's for, what's in it, whether it's fragile. The server reads the labels before it opens the package.

📝 **Terminology.** **Header** = one `Name: Value` line of metadata on an HTTP message. **Body** = the actual content (the HTML, the JSON, the image). Headers describe; the body delivers.

A handful you'll genuinely run into:

- **`Content-Type`** - what kind of thing the body is: `text/html` for a page, `application/json` for data, `image/png` for an image. This is how your browser knows whether to *draw* the body or *download* it.
- **`Authorization`** - proof of who you are, when a request needs it. The proper place for a secret token or credentials - a header, not stapled into the visible URL (remember the query-string warning from [Phase 1](01-request-and-response.md)).
- **`User-Agent`** - a description of the client itself (which browser, which version) - how a server tells a phone from a desktop.
- **`Cache-Control`** - instructions about reuse: "keep a copy for an hour" versus "always ask me fresh."

Here's a request and the start of its response, headers and all:

```http
GET /account HTTP/1.1
Host: example.com
Authorization: Bearer a1b2c3d4e5
Accept: text/html
```
```http
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: no-store

<!DOCTYPE html> ...
```
*What just happened:* the client proved who it was with an `Authorization` header (the `Bearer ...` token is its ID badge) and asked for HTML back. The server approved, labelled its answer `Content-Type: text/html` so the browser knows to render it, and added `Cache-Control: no-store` - "don't keep a copy of this account page lying around." Neither side put any of that in the URL or the body; the headers carried it.

Half the puzzling moments in web work are a header doing its job quietly - a file downloading instead of displaying (wrong `Content-Type`), a request rejected as unauthorized (missing `Authorization`), a page stubbornly showing old content (`Cache-Control`). Once you know headers exist, those stop being mysteries and become a place to look.

## Cookies - how a site remembers you

HTTP has a problem by nature: each request stands completely alone. The server answers and then, in effect, *forgets you exist* - the next request is a stranger all over again. So how does a site keep you logged in across a dozen clicks? With a **cookie**.

📝 **Terminology.** A **cookie** is a small piece of text a server asks your browser to hold onto and hand back on every future request to that site - the site's way of pinning a name tag on you.

The mechanism is two ordinary headers, one on the way down, one on the way back up:

```http
HTTP/1.1 200 OK
Set-Cookie: session=7f3a9b2c; HttpOnly; Secure
```
*What just happened:* when you logged in, the server's response included `Set-Cookie`: "here's a token, `session=7f3a9b2c` - hold onto this." Your browser quietly saved it. `HttpOnly` and `Secure` are guardrails, telling the browser to keep the cookie out of reach of page scripts and to send it only over encrypted connections.

From then on, your browser includes it automatically on every request back to that site:

```http
GET /account HTTP/1.1
Host: example.com
Cookie: session=7f3a9b2c
```
*What just happened:* the browser attached the cookie in a `Cookie` header, without you doing anything. The server reads `session=7f3a9b2c`, looks it up, recognizes "this is the person who logged in earlier," and shows your account. `Set-Cookie` down, `Cookie` back up on every request - that's how a stack of forgetful, independent requests adds up to *staying logged in*.

That same mechanism is why cookies get talked about for tracking: a cookie that follows you around can recognize you across pages and visits. The technology is neutral - the same name tag whether it's keeping you logged in or watching where you go.

⚠️ **Gotcha.** A cookie is only as private as the connection it travels on. Over plain `http://`, anyone sitting between you and the server can *read* that `Cookie: session=...` header as it goes by - and a stolen session cookie can let someone impersonate you without ever knowing your password. This is the single biggest reason the next section exists: cookies and HTTPS are a package deal.

## The S in HTTPS - encryption, plainly

`https://` is the same HTTP you've learned this whole guide - same requests, responses, headers - wrapped in a layer that **encrypts** the conversation. The "S" stands for "Secure," and it buys you two things:

- **Privacy.** Anyone who can see your traffic - café Wi-Fi, your ISP, a machine in the middle - sees only scrambled noise, not the page you're reading or the cookie you're sending.
- **Integrity.** Nobody in the middle can quietly *alter* the page on its way to you - inject an ad, swap a download, change an account number. Tampered bytes are detectable.

(There's a third thing - confidence you're really talking to who you think you are, via certificates - but privacy and integrity are the heart of it.)

A common belief is that HTTPS means "this website is safe / trustworthy." It doesn't. HTTPS protects the *conversation*, not the *intentions* of whoever's on the other end - a scam site can have a perfect padlock. The padlock means "no one is eavesdropping on or tampering with what you send" - not "this server is run by good people." Conflating those is how people get caught out.

The encryption HTTPS adds doesn't live *inside* HTTP - it's a separate layer (called TLS) sitting just beneath it, scrambling bytes before they're sent and unscrambling them on arrival. HTTP doesn't even know it's there. Where that layer sits relative to everything else is the job of [The TCP/IP Model](/guides/tcp-ip-model).

⚠️ **Gotcha - mixed content.** A page loaded over `https://` is only fully protected if *everything* on it also came over `https`. If a secure page pulls in an image, script, or stylesheet over plain `http://`, that's **mixed content** - one insecure piece reopening the hole HTTPS was closing, since it can be read or tampered with in transit. Browsers block the insecure parts or strip the padlock and warn you. A "not fully secure" warning on a site that should be secure usually means one stray `http://` link on an otherwise `https://` page.

## Recap

1. **Headers** are `Name: Value` notes carrying metadata about a message - `Content-Type` (what the body is), `Authorization` (who you are), `Cache-Control` (whether to reuse it), and many more.
2. **Cookies** solve HTTP's forgetfulness: the server sends one with `Set-Cookie`, your browser hands it back in a `Cookie` header on every request, and that's how you "stay logged in."
3. A cookie is only as safe as its connection - over plain `http`, it can be read and stolen.
4. **HTTPS** is HTTP plus encryption: it gives you **privacy** (no eavesdropping) and **integrity** (no tampering) - but *not* a promise that the site itself is trustworthy.
5. **Mixed content** - an `http` resource on an `https` page - quietly undoes that protection, which is why browsers warn about it.

That's the whole everyday picture of HTTP: a request and a response (Phase 1), the verbs and replies they use (Phase 2), and the headers, cookies, and encryption that ride along (Phase 3). You can now read a request, read a response, read a status code, and read the address bar - which is most of what the web is doing, all day, under everything you click.

> Want to go a layer deeper - how the bytes actually travel, how a name like `example.com` becomes a
> machine you can reach, and where encryption sits in the stack? Continue with
> [How the Internet Works](/guides/how-the-internet-works),
> [IP, DNS, and Ports](/guides/ip-dns-and-ports), and [The TCP/IP Model](/guides/tcp-ip-model).