HTTP Status Codes Reference
Complete list of HTTP status codes with descriptions and examples. Learn 200, 301, 404, 500 error codes. Free HTTP response code reference guide
Every developer knows 200, 404, and 500. The interesting status codes are the ones you reach for once a year and have to look up: when do you use 409 vs 422? Is 401 about authentication or authorization? When is a 301 a mistake that costs you SEO? This reference covers all 60+ codes registered with IANA, with the practical "use this when" rule alongside the formal RFC definition, and flags the codes that are commonly misused.
The five classes and what they really mean
- 1xx Informational — almost never seen at the application layer. 100 Continue is for "I am about to send a big body, is that OK?" handshakes; 101 Switching Protocols is HTTP→WebSocket. If you are writing an app and considering returning a 1xx, you are probably wrong.
- 2xx Success — the request was understood and accepted. 200 (generic success), 201 (resource created), 204 (success with no body), 206 (partial content for Range requests).
- 3xx Redirection — the client should look somewhere else. 301 (permanent — search engines update their index), 302 (temporary), 303 (POST → GET pattern), 304 (cached resource still valid), 307/308 (preserve the original method on redirect).
- 4xx Client Error — the request was bad and the client should change something. 400 (malformed), 401 (not authenticated), 403 (authenticated but not allowed), 404 (not here), 409 (conflict), 410 (was here, intentionally gone), 422 (semantically wrong), 429 (too many requests).
- 5xx Server Error — the server failed to fulfill a valid request. 500 (generic), 502 (bad gateway, upstream failed), 503 (overloaded or in maintenance), 504 (upstream timeout).
The codes everyone confuses
401 vs 403: 401 means "I do not know who you are, send credentials". 403 means "I know who you are and you cannot access this". If your app returns 401 for "valid user, wrong permissions" you are wrong. WWW-Authenticate header is mandatory on a 401 per RFC 9110; almost no API actually sends it.
422 vs 400: 400 means "I cannot parse this request at all" (malformed JSON, missing required header). 422 means "I parsed it fine but the semantics are wrong" (email format invalid, conflict with business rules). Most APIs return 400 for both; the distinction matters for client-side error handling.
301 vs 308 (and 302 vs 307): the 301/302 status codes historically allowed clients to switch the request method from POST to GET on redirect, which many do. 308 and 307 are the strict-method-preserving versions. For redirecting form submissions, always use 307 or 308.
404 vs 410: 404 means "I do not know if this ever existed". 410 means "this existed and is now intentionally gone". Search engines drop 410'd URLs from the index faster than 404'd ones. Use 410 when you delete content on purpose.
Working example: REST CRUD response codes
Input
A typical REST resource lifecycle (POST/GET/PUT/PATCH/DELETE)
Output
POST /users with valid body → 201 Created (+ Location header) POST /users with duplicate email → 409 Conflict POST /users with malformed JSON → 400 Bad Request POST /users with invalid email format → 422 Unprocessable Entity GET /users/123 (exists) → 200 OK GET /users/123 (never existed) → 404 Not Found GET /users/123 (deleted on purpose) → 410 Gone PUT /users/123 with full body → 200 OK or 204 No Content PATCH /users/123 partial update → 200 OK PATCH /users/123 violating constraint → 422 or 409 DELETE /users/123 → 204 No Content DELETE /users/123 (already deleted) → 204 (idempotent) or 404
There is no RFC-mandated answer for "DELETE an already-deleted resource". Returning 204 (idempotent — the desired end-state is reached) is more idiomatic than 404 (the thing you asked about does not exist).
When to reach for this reference
- You are designing an API endpoint and want to confirm 409 vs 422 vs 400 for a specific validation failure.
- You inherited an API that returns 200 with {"error": "..."} bodies and you want a counter-argument with RFC numbers for switching to proper status codes.
- You are configuring a CDN or reverse-proxy rule that maps origin responses to client responses and need to know which codes are safe to forward unchanged.
- You are debugging a redirect chain and want to confirm whether 301 vs 307 is causing your POST data to be lost.
What this reference will not do
- It will not enforce that your framework actually sends the right code. Express, Django, Spring, FastAPI — each has its own defaults that can quietly downgrade 422 to 400. Inspect the wire output, not the framework documentation.
- It will not advise on browser-specific behavior. Browsers handle some codes opinionatedly: a 405 Method Not Allowed on the redirect target of a form POST has unpredictable UX.
- It will not cover non-standard codes (418 I'm a Teapot is a joke; 420 Method Failure was Spring's mistake; 444/494/499 are nginx internals). Use only IANA-registered codes for cross-system compatibility.
Frequently asked questions
When should I return 204 instead of 200 with an empty body?
204 specifically signals "success, no representation to return". Use it for DELETE responses and for PUT/PATCH if you do not return the updated resource. 200 with empty body is technically valid but semantically less precise — and some clients treat 204 specially (no body parsing attempted).
Is it OK to return 200 with an error in the JSON body?
Not for a transport-level error. Status codes are how HTTP signals success/failure to caches, proxies, monitoring tools, and clients. Returning 200 for "user not found" means your error rate dashboard shows zero errors even when 30% of requests fail. Use the right status code; put error details in the body.
What is the difference between 301 and 302 for SEO?
301 (permanent) tells search engines to drop the old URL from the index and replace with the new one. 302 (temporary) tells them to keep the old URL. Using 302 for a permanent move is the most common SEO mistake — old URL keeps ranking, new URL never accumulates link equity.
When do I use 429 Too Many Requests?
When you reject a request because the caller has exceeded a rate limit. Always include a Retry-After header (seconds, or an HTTP-date). Without Retry-After, clients have to guess, which defeats the purpose.
Are 5xx errors logged differently than 4xx?
They should be. 5xx is "we failed" — every 5xx is a bug or operational issue. 4xx is "you failed" — usually a client bug, sometimes intentional (a deliberate 401 to prompt login). Monitor 5xx rate as part of SLO; 4xx rate matters only for specific endpoints (login 401s, search 404s).
What is HTTP 451?
451 Unavailable For Legal Reasons — defined in RFC 7725 (named after Bradbury's Fahrenheit 451). Use it when content is blocked by court order, DMCA takedown, or government censorship. Distinguish from 403 (you cannot access this for non-legal reasons) and 410 (this is gone for any reason).
Related tools
Debug CORS issues, analyze headers, generate server configurations. Support for Express, Nginx, Apache, Django, Flask, Spring Boot. Learn CORS concepts. Free online CORS tester
Generate mock API responses with fake JSON data. Create realistic REST API test data. Free mock server response generator for developers
Decode and inspect JWT tokens. View header, payload, signature. Verify JWT expiration and claims. Free online JSON Web Token decoder and debugger
Generate SEO meta tags, Open Graph, Twitter Cards with live preview. Optimize website metadata for search engines and social sharing
Build Content-Security-Policy headers visually. Add directives, sources, preview policy. Free online CSP generator for web security
Parse and analyze browser User-Agent strings. Detect browser, OS, device type from UA. Free online User-Agent decoder and analyzer
Last updated · E-Utils editorial team