Every time you load a web page, your browser and the server have a short conversation you never see. The browser asks for something; the server answers with a three-digit number that says how the request went. Those numbers are HTTP status codes, and learning to read them is one of the fastest ways to stop guessing when a site misbehaves.
Where status codes come from
HTTP — the Hypertext Transfer Protocol — is the set of rules browsers and servers use to exchange information. A request travels from the client (your browser, a mobile app, a script) to the server. The server sends back a response, and the very first line of that response contains the status code.
The code is machine-readable on purpose. A browser needs to know instantly whether to render a page, follow a redirect, show a cached copy, or display an error. Humans benefit too: the same number tells a developer roughly where the problem lives.
The five classes
Status codes are grouped by their first digit. Before memorising individual codes, learn the five families — they already tell you most of what you need.
| Class | Meaning | Short version |
|---|---|---|
| 1xx | Informational | “Still working on it.” |
| 2xx | Success | “Here you go.” |
| 3xx | Redirection | “It lives somewhere else.” |
| 4xx | Client error | “Your request has a problem.” |
| 5xx | Server error | “My side broke.” |
That last distinction matters more than any individual code. A 4xx points the investigation toward the request: the URL, the method, the headers, the credentials. A 5xx points it toward the server: the application code, the database, the configuration.
2xx: the ones you rarely notice
- 200 OK — the standard success response. The request worked and the body contains what you asked for.
- 201 Created — a new resource was created. Common after a POST that adds a record.
- 204 No Content — it worked, and there is deliberately nothing to send back. Useful for deletes and simple updates.
Successful codes are invisible in normal browsing, which is why many people only ever meet the error ones. When you build an API, though, choosing between 200, 201 and 204 is part of designing a clear contract for the people who will consume it.
3xx: redirects, and why 301 vs 302 matters
Redirect codes tell the client to go somewhere else. The interesting part is the difference between “permanently” and “temporarily”, because browsers and search engines treat them differently.
- 301 Moved Permanently — the resource has a new home for good. Browsers cache it aggressively, and search engines transfer ranking signals to the new URL.
- 302 Found — a temporary move. The original URL is expected to come back, so the old address keeps its standing.
- 304 Not Modified — the cached copy the client already has is still valid, so the server skips sending the body. This is a quiet but major contributor to page speed.
- 307 and 308 — stricter versions of 302 and 301 that guarantee the HTTP method is not changed during the redirect.
A practical warning: because browsers cache 301s, a permanent redirect set by mistake can be painful to undo for users who already visited the page. When in doubt during a migration, start with a temporary redirect and switch to permanent once you are sure.
4xx: when the request is the problem
- 400 Bad Request — the server could not understand the request. Malformed JSON and invalid parameters are typical causes.
- 401 Unauthorized — authentication is missing or invalid. Despite the name, it means “not authenticated”.
- 403 Forbidden — the server knows who you are and still refuses. You are authenticated but not allowed.
- 404 Not Found — nothing exists at that address. The single most famous code on the web.
- 405 Method Not Allowed — the URL exists, but not for that verb. Sending POST to an endpoint that only accepts GET, for example.
- 409 Conflict — the request clashes with the current state, such as creating a user whose email is already registered.
- 422 Unprocessable Content — the syntax is fine but the data fails validation rules.
- 429 Too Many Requests — you hit a rate limit. Slow down and retry later.
The 401 versus 403 confusion is worth internalising, because it changes what you do next. A 401 usually means “log in or refresh the token”. A 403 means “the account you are using does not have permission” — logging in again will not help.
5xx: when the server is the problem
- 500 Internal Server Error — a generic failure. Something threw an unhandled exception. The real answer is in the server logs.
- 502 Bad Gateway — a server acting as a proxy got an invalid response from the server behind it. Common when an application process has crashed behind a reverse proxy.
- 503 Service Unavailable — the server is temporarily unable to handle the request, often during maintenance or overload.
- 504 Gateway Timeout — the upstream server took too long to answer.
For users, all 5xx codes look the same: the site is broken. For whoever maintains it, the distinction narrows the search considerably. A 502 or 504 usually points at the layer between the proxy and the application, while a 500 points at the application itself.
Reading status codes yourself
You do not need special tools to see these codes. Open your browser’s developer tools, switch to the Network tab and reload the page. Every request is listed with its status, and you can watch redirect chains resolve step by step.
On the command line, a request made with a tool like curl can display response headers, including the status line. When debugging an API, checking the raw status before reading the response body often saves time — the body may be empty or misleading, but the code rarely lies.
A common trap: the soft 404
Some sites display a friendly “page not found” message while the server still returns 200 OK. Visitors see an error; machines see success. Search engines may then index the empty page, and monitoring tools never raise an alert because, technically, nothing failed.
The fix is to make the code match reality: a missing page should return 404 (or 410 if it was intentionally removed), even when the design is friendly. The status code is the part machines trust.
Conclusion
Status codes turn vague complaints like “the site is down” into a starting point. Knowing the five classes tells you whose problem it is; knowing a handful of specific codes tells you where to look next. It is a small amount of knowledge with an unusually good return.
If you want to go deeper into how the web actually works — requests, APIs, servers and debugging — the free web development and backend courses on Cursa cover these foundations step by step, with plenty of hands-on practice.
