← All Articles

HTTP Status Codes Explained: Every Code You Will Actually Meet

At a Glance
Response status 4xx or 5xxAPI returning unexpected codesNeed to choose the right code to return

The dividing line: 4xx means the request was wrong (fix the caller), 5xx means the server failed (fix the service). Get that split right and most status-code bugs resolve themselves.

The Reference Table

CodeNameMeansTypical cause / fix
200OKSuccess with body—
201CreatedResource createdReturn Location header with the new resource URL
204No ContentSuccess, no bodyCorrect for DELETE and update-without-response
206Partial ContentRange request servedVideo streaming, resumable downloads
301Moved PermanentlyNew URL foreverHTTP→HTTPS, domain migration; browsers cache it hard
302 / 307Found / Temporary RedirectMoved temporarily307 preserves the HTTP method; 302 historically does not
304Not ModifiedYour cached copy is currentNormal ETag/If-None-Match flow, not an error
308Permanent RedirectLike 301 but method-preservingAPI version moves
400Bad RequestMalformed requestInvalid JSON, missing required field, bad query param format
401UnauthorizedNot authenticatedMissing/expired token. Name is wrong — it means "unauthenticated"
403ForbiddenAuthenticated but not allowedValid token, insufficient role/scope
404Not FoundNo such resourceWrong URL, deleted resource, or deliberately hidden resource
405Method Not AllowedWrong HTTP verbPOSTing to a GET-only endpoint; check the Allow header
408Request TimeoutClient too slowRare; usually seen through proxies
409ConflictState conflictDuplicate create, concurrent edit; safe to retry after re-reading
410GoneDeliberately removedStronger than 404; tells indexers to drop the URL
413Payload Too LargeBody exceeds limitRaise the limit or chunk the upload
415Unsupported Media TypeWrong Content-TypeSend application/json when the API expects it
422Unprocessable EntityWell-formed but semantically invalidValidation errors; the request parsed but the values are wrong
429Too Many RequestsRate limitedBack off; honor Retry-After
500Internal Server ErrorUnhandled server exceptionCheck server logs — the response intentionally hides the cause
502Bad GatewayUpstream sent garbage or diedApp crashed behind the proxy; check upstream health
503Service UnavailableServer can't handle it right nowOverload or maintenance; often has Retry-After
504Gateway TimeoutUpstream too slowLong query, deadlock, or an upstream that hangs

The 401 vs 403 Confusion, Settled

401 Unauthorized is named badly — it means unauthenticated: the server does not know who you are (no token, expired token, malformed header). 403 Forbidden means the server knows exactly who you are and you still cannot do this (wrong role, missing scope, IP blocked). Practical consequence: a 401 should trigger a login/refresh flow in clients; a 403 must not — retrying with the same credentials will never succeed. The full 401 vs 403 guide covers the debugging recipes.

The Codes That Indicate You (the Client) Erred

400, 404, 405, 413, 415, 422 and friends mean the request itself was the problem. The debugging question is never "why is the server broken" but "what exactly did I send?" The fastest tool is the raw request: curl with -v shows headers and body as sent, before any HTTP library massages them.

curl -v -X POST https://api.example.com/users \
  -H "Content-Type: application/json" \
  -d '{"name": "x"}'

Common mismatches: Content-Type says form-encoded while the body is JSON (→ 415 or 400), trailing slash redirect on POST (→ 405 after the redirect), and empty body on a required-field endpoint (→ 400/422 depending on the framework).

The Codes That Indicate the Server Erred

500 means an exception escaped your handler — the fix is in the server log, always. 502/504 mean an intermediary (nginx, Cloudflare, an API gateway) could not get a good answer from the app: 502 usually means the app process is dead or crashed mid-request, 504 means it is alive but slower than the proxy's timeout. The distinction matters: a 502 is a health/lifecycle problem, a 504 is a performance problem. The 500 guide walks through the log-to-cause path.

Choosing Codes When Building an API

Rules that prevent arguments in code review: (1) created → 201 with Location; (2) validation failure → 422 (or 400, but pick one convention); (3) auth missing → 401, insufficient permission → 403; (4) duplicate resource → 409; (5) rate limit → 429 with Retry-After; (6) never return 200 with an error body — clients and monitors will both lie to you. The last one is the most expensive anti-pattern: it defeats every status-code-based alert you will ever write.

Related Errors

401 vs 403 · 500 Internal Server Error