HTTP Status Code Lookup
Look up any HTTP status code — what it means and when servers send it.
35 codes
Continue
The server has received the request headers and the client should proceed to send the request body.
Switching Protocols
The server is switching protocols as requested by the client (e.g. to WebSocket).
OK
The request succeeded. The meaning depends on the HTTP method used.
Created
The request succeeded and a new resource was created as a result.
Accepted
The request has been received but not yet acted upon.
No Content
There is no content to send, but the request succeeded.
Partial Content
Used for range requests — the server is delivering only part of the resource.
Moved Permanently
The resource has been permanently moved to a new URL.
Found
The resource temporarily resides at a different URL.
Not Modified
The resource has not changed since the version specified in the request headers.
Temporary Redirect
Like 302, but the request method and body must not change.
Permanent Redirect
Like 301, but the request method and body must not change.
Bad Request
The server could not understand the request due to invalid syntax.
Unauthorized
Authentication is required and has failed or not been provided.
Payment Required
Reserved for future use — rarely seen outside of API rate-limiting schemes.
Forbidden
The client does not have access rights to the content, even if authenticated.
Not Found
The server can't find the requested resource.
Method Not Allowed
The request method is known but not supported by the target resource.
Not Acceptable
No content matching the criteria in the Accept headers could be produced.
Request Timeout
The server timed out waiting for the request.
Conflict
The request conflicts with the current state of the target resource.
Gone
The resource requested is no longer available and will not be available again.
Length Required
The server refuses the request because the Content-Length header was not defined.
Payload Too Large
The request entity is larger than limits defined by the server.
URI Too Long
The URI requested by the client is longer than the server is willing to interpret.
Unsupported Media Type
The media format of the requested data is not supported by the server.
I'm a teapot
A joke status code from RFC 2324 — the server refuses to brew coffee because it is a teapot.
Unprocessable Entity
The request was well-formed but contains semantic errors.
Too Many Requests
The user has sent too many requests in a given amount of time (rate limiting).
Internal Server Error
The server has encountered a situation it doesn't know how to handle.
Not Implemented
The request method is not supported by the server and cannot be handled.
Bad Gateway
The server, acting as a gateway, got an invalid response from the upstream server.
Service Unavailable
The server is not ready to handle the request — often due to maintenance or overload.
Gateway Timeout
The server, acting as a gateway, did not get a response in time from the upstream server.
HTTP Version Not Supported
The HTTP version used in the request is not supported by the server.
A searchable reference for every HTTP status code — what it means, when a server should send it, and what a client should do when it receives one. Useful when debugging an API response or deciding which code your own endpoint ought to return.
The first digit tells you the category: 1xx informational, 2xx success, 3xx redirection, 4xx the client made a mistake, 5xx the server did. That alone resolves most questions about who needs to fix what.
The codes you'll meet most often
| Code | Meaning | When to use it |
|---|---|---|
| 200 OK | Success | A normal successful GET or PUT |
| 201 Created | Resource created | A POST that created something; include a Location header |
| 204 No Content | Success, nothing to return | A successful DELETE |
| 301 / 308 | Permanent redirect | The URL has moved for good; 308 preserves the method |
| 302 / 307 | Temporary redirect | Short-term move; 307 preserves the method |
| 304 Not Modified | Cached copy is current | Conditional GET with a matching ETag |
| 400 Bad Request | Malformed request | Syntactically invalid input |
| 401 Unauthorized | Not authenticated | Missing or invalid credentials |
| 403 Forbidden | Authenticated but not allowed | Valid identity, insufficient permission |
| 404 Not Found | No such resource | Also used to hide the existence of a resource |
| 409 Conflict | State conflict | Duplicate key, concurrent edit |
| 422 Unprocessable | Valid syntax, invalid semantics | Validation failures |
| 429 Too Many Requests | Rate limited | Include a Retry-After header |
| 500 Internal Server Error | Unhandled failure | The catch-all bug response |
| 502 / 503 / 504 | Gateway, unavailable, timeout | Upstream problems, not your handler's logic |
The distinctions people get wrong
- 401 vs 403: 401 means 'I don't know who you are' — retry with credentials. 403 means 'I know who you are and you still can't'. Retrying won't help.
- 400 vs 422: 400 is for a request that couldn't be parsed; 422 is for one that parsed fine but failed business validation.
- 301 vs 302: 301 is cached aggressively by browsers, sometimes permanently. Don't use it for anything you might reverse.
- 302 vs 307: older clients change POST to GET on a 302. 307 and 308 guarantee the method is preserved.
- 200 with an error body: a genuinely common anti-pattern. If the request failed, the status code should say so — clients and proxies rely on it.
- 404 vs 410: 410 Gone says the resource existed and was deliberately removed, which helps search engines de-index it faster.
Codes worth knowing about
418 I'm a teapot comes from an April Fools' RFC in 1998 and is not a real status code, though several frameworks implement it anyway. 451 Unavailable For Legal Reasons is real, and is named after Fahrenheit 451.
On the practical side: 429 should always carry a Retry-After header so clients can back off correctly, and 503 should too when the outage is planned. A rate limiter that returns 429 with no guidance just produces retry storms.
Frequently asked questions
- What's the difference between 401 and 403?
- 401 Unauthorized means you aren't authenticated — send credentials and try again. 403 Forbidden means you are authenticated but lack permission, so retrying with the same identity will never work.
- Should a validation error return 400 or 422?
- 400 for a request the server couldn't parse, 422 for one that parsed correctly but failed business rules. Many APIs use 400 for both, which is acceptable if applied consistently.
- When should I use 301 instead of 302?
- 301 for a move you're certain is permanent — browsers and search engines cache it hard, sometimes indefinitely. Use 302 or 307 for anything temporary or reversible.
- Is it acceptable to return 200 with an error inside the body?
- It's a common anti-pattern. Caches, proxies, monitoring tools and client libraries all interpret the status code, so signalling failure with a 200 defeats every layer above your handler.
- What does 418 I'm a teapot actually mean?
- It comes from a 1998 April Fools' RFC for the Hyper Text Coffee Pot Control Protocol. It isn't a real status code, though several frameworks implement it as a joke.
- Which code should a rate limiter return?
- 429 Too Many Requests, with a Retry-After header telling the client how long to wait. Without that header, well-behaved clients have no way to back off correctly.