HTTP Status Codes That Actually Matter

There are ~75 official HTTP status codes. You’ll encounter about 15 of them regularly. Here they are, grouped by what they mean in practice.

2xx — It Worked

• 200 OK — The request succeeded and here’s your data. The one you want to see.
• 201 Created — The thing you asked to create (user, post, resource) now exists. Typical response to a successful POST.
• 204 No Content — It worked, but there’s nothing to send back. Common for DELETE requests — the thing is gone, what would I return?

3xx — Go Somewhere Else

• 301 Moved Permanently — This URL has moved forever. Browsers and search engines will update their bookmarks. Use this when you rename a route and never want the old one back.
• 302 Found — Temporary redirect. The resource is at a different URL right now, but keep using this one in the future. Login flows use this constantly.
• 304 Not Modified — You already have the latest version (your cache is fine). The server checked your If-Modified-Since header and said “nothing changed, use what you have.”

4xx — You Messed Up

• 400 Bad Request — The server can’t understand what you sent. Malformed JSON, missing required fields, invalid query parameters. Check your request body.
• 401 Unauthorized — You’re not logged in (or your token expired). Despite the name, this is about authentication, not authorization — the server doesn’t know who you are.
• 403 Forbidden — The server knows who you are and you’re not allowed. Unlike 401, logging in again won’t help — you don’t have permission.
• 404 Not Found — Nothing exists at this URL. Either the route is wrong, the resource was deleted, or you have a typo. The most famous status code for a reason. (In DNS resolution, the equivalent is NXDOMAIN — “this domain doesn’t exist.”)
• 405 Method Not Allowed — The URL exists, but not for that HTTP method. You sent a DELETE to an endpoint that only accepts GET. Check your method.
• 422 Unprocessable Entity — The JSON is valid, but the data doesn’t make sense. Your email field contains “not-an-email” or the date is in the wrong format. Many APIs use this instead of 400 for validation errors.
• 429 Too Many Requests — You’re being rate-limited. Slow down. Check the Retry-After header to know when you can try again. (This is the signal bot detection systems use to push back on aggressive clients, and the one AIMD rate limiting is designed to react to automatically.)

5xx — The Server Messed Up

• 500 Internal Server Error — Something crashed on the server. An unhandled exception, a null pointer, a database query that blew up. Not your fault as the client — check server logs.
• 503 Service Unavailable — The server is down or overloaded. Deployments, maintenance windows, and traffic spikes all produce this. Usually temporary — try again in a minute.

Quick Decision Guide

You see…	First thing to check
401	Is your auth token present and not expired?
403	Does this user/role have permission for this action?
404	Is the URL correct? Is the resource ID valid?
422 vs 400	400 = bad syntax, 422 = bad semantics. Check API docs for which one they use.
429	Read the Retry-After header. Add exponential backoff.
500	Not a client problem. Check server logs, not your request.
503	Wait and retry. If persistent, check if the service is deploying or down.

Sources

• IETF, RFC 9110: HTTP Semantics
• IETF, RFC 6585: Additional HTTP Status Codes
• MDN, HTTP response status codes