The first digit is the only part you have to memorise
Every status code is three digits and the first one classifies the rest. 1xx is a progress signal, 2xx worked, 3xx means go somewhere else, 4xx blames the request, 5xx blames the server. That is enough to triage a code you have never seen: on a 4xx, look at the URL, the method, the headers and the credentials you sent; on a 5xx, stop reading the response body and open the server logs, because the body is usually a generic error page written by someone who had no idea what would fail.
The dividing line between 4xx and 5xx is about fault, not about who noticed. A 500 raised because a user submitted an unexpected value is still a 500 — the server crashed on input it should have rejected with a 400.
401 and 403
401 means the server does not know who you are. It is required to send a WWW-Authenticate header, and the implied next step is to authenticate and try again. 403 means the server does know who you are and is refusing anyway; retrying with the same identity will never work. The practical failure is an API that returns 401 for a permissions problem: the client's interceptor sees 401, clears the session, redirects to the login page, the user signs in with the same account, hits the same endpoint, and loops. If the token is valid and the account simply lacks the right, the answer is 403.
There is one legitimate reason to bend this. If admitting a resource exists is itself a leak — a private repository, another tenant's record — returning 404 rather than 403 is standard practice, because 403 confirms the thing is there.
301, 302, 307 and 308, and which ones keep your method
Two axes: permanent or temporary, and method-preserving or not. 301 and 308 are permanent; 302 and 307 are temporary. 307 and 308 preserve the method and body, so a redirected POST arrives as a POST. 301 and 302 do not, in practice: the original specifications forbade changing the method, browsers did it anyway, and RFC 7231 eventually wrote the existing behaviour into the standard as permitted.
So for an HTML page that has moved, 301 is right and the method rewrite is harmless, because it was a GET. For an API endpoint that has moved, 301 is a trap — a client POSTing JSON gets silently converted into a GET and receives a confusing 405 or an empty list. Use 308 there. And remember that browsers cache 301 and 308 persistently; a wrong permanent redirect keeps firing from the user's own cache after you have fixed the server, which is why deploying a 302 first and promoting it later is a common precaution.
303 is the odd one out and deserves more use than it gets. It forces a GET on purpose, which is the Post/Redirect/Get pattern: the browser lands on a URL it can safely refresh, and hitting reload does not resubmit the payment.
404 and 410
404 says there is nothing here and makes no claim about history. 410 says there was something here, it was removed deliberately, and it is not coming back. Search engines treat the second as a stronger signal and drop the URL sooner, so 410 is the right code for a retired product page or a takedown. If you are not sure — a typo'd URL, a deleted row you might restore — 404 is the honest answer.
502, 503 and 504
All three usually come from a reverse proxy rather than from your application, and the difference tells you where to look. 502 means the proxy got a reply it could not use, or no reply at all: the process is down, listening on the wrong port, or crashed mid-response. 503 means something deliberately said no — the application returned it during maintenance, or the load balancer has no healthy instances left. 504 means the upstream was there, accepted the request, and ran past the proxy's timeout, which points at a slow query or a blocking external call rather than a crash.
The tempting fix for a 504 is to raise proxy_read_timeout. That converts a fast failure into a slow one and moves the pileup into your connection pool.
Choosing codes for an API you are writing
Use 201 with a Location header for creation, 204 for a success with nothing to say, 202 for work you have queued, 409 for a conflict the client can resolve, 412 for a failed precondition, 422 for a body that parsed but did not validate, and 429 with Retry-After for rate limits. Avoid the pattern of returning 200 with {"success": false} for everything: it defeats HTTP caching, makes every monitoring dashboard report a healthy service while it is failing, and forces every client to parse a body before it can tell whether the call worked.
One thing this table cannot help with: a CORS failure is not a status code. The server may well have returned 200 and the browser simply refused to hand the response to your JavaScript. Look in the console for the specific rule that was violated and at the Access-Control-Allow-Origin header on the response, not at the status.
Questions people ask
Is 304 an error?
No. It is a successful conditional request. The client asked whether its cached copy was still current, and the server said yes without resending the body. Seeing a lot of them in devtools means your caching headers are doing their job. The only way 304 becomes a problem is if the server sends it when the resource genuinely has changed, which usually means the ETag is computed from something that does not vary with the content.
When should I return 400 and when 422?
If the request could not be parsed — malformed JSON, a bad multipart boundary, an unparseable query string — that is 400, and it is often the framework answering before your code runs. If the request parsed cleanly and the problem is with the values, 422 is the more precise answer and gives you an obvious place to attach a field-level error list. This split is convention rather than a hard rule; the important part is that a single API is consistent about it.
Which codes do search engines actually act on?
301 and 308 transfer ranking signals to the new URL. 302 and 307 indicate the original URL should stay indexed. 404 removes a page slowly, 410 removes it faster. 503 with a Retry-After header is the correct way to say the site is temporarily down during a deployment, and crawlers will come back rather than dropping the pages. Serving a 200 with an error page is the worst option, because it gets indexed.
Why do I see codes that are not in this list, like 499 or 520?
They are vendor extensions rather than registered codes. Nginx logs 499 when the client disconnects before the response is written — it never goes over the wire. Cloudflare uses 520 through 530 to distinguish origin failures its own proxy detected. Various frameworks use 419 or 440 for expired sessions. None are defined by the HTTP specification, so the vendor documentation is the only authority on them.