HTTP Status Codes
Searchable reference for every HTTP status code with descriptions and RFC links.
61 results
1xx Informational
Request received, continuing process.
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. WebSocket upgrade).
Processing
WebDAV: the server has received and is processing the request, but no response is available yet.
Early Hints
Used to return preliminary headers (e.g. Link) before the final response.
2xx Success
Request received, understood, and accepted.
OK
Standard success response. The body contains the requested resource or operation result.
Created
Request succeeded and a new resource was created. Location header should point to it.
Accepted
Request accepted for processing but not yet completed (asynchronous handling).
Non-Authoritative Information
The returned metadata is from a transforming proxy, not the origin server.
No Content
Success with no response body. Common for DELETE and PUT operations.
Reset Content
Success; the client should reset the document view (e.g. clear a form).
Partial Content
Used for range requests. The body contains only the requested byte range.
Multi-Status
WebDAV: body contains an XML document with multiple independent status codes.
Already Reported
WebDAV: members of a binding already enumerated and won't be repeated.
IM Used
Server fulfilled a GET using delta encoding (instance manipulations).
3xx Redirection
Further action needed to complete the request.
Multiple Choices
Multiple representations available; the user or agent should choose one.
Moved Permanently
Resource permanently moved to the URL in the Location header. Cacheable.
Found
Resource temporarily at a different URL. Method may change to GET historically.
See Other
Response to the request can be found at another URL via GET (Post/Redirect/Get).
Not Modified
Cached version is still valid. Sent in response to conditional GET requests.
Temporary Redirect
Temporary redirect that preserves the original HTTP method and body.
Permanent Redirect
Permanent redirect that preserves the original HTTP method and body.
4xx Client Error
Request contains bad syntax or cannot be fulfilled.
Bad Request
Server cannot process the request due to malformed syntax or invalid input.
Unauthorized
Authentication required or has failed. Use WWW-Authenticate header.
Payment Required
Reserved for future use. Sometimes used by APIs to signal quota or billing issues.
Forbidden
Server understood the request but refuses to authorize it. Authentication won't help.
Not Found
The requested resource does not exist on the server.
Method Not Allowed
Method is not supported for this resource. Allow header lists valid methods.
Not Acceptable
Resource cannot produce a response matching the Accept headers in the request.
Proxy Authentication Required
Client must authenticate with the proxy first.
Request Timeout
Server timed out waiting for the request. The client may repeat without modification.
Conflict
Request conflicts with the current state (e.g. version conflict, duplicate).
Gone
Resource is permanently gone with no forwarding address. Stronger than 404.
Length Required
Server requires a Content-Length header.
Precondition Failed
A precondition (e.g. If-Match) in the request headers was not met.
Content Too Large
Request body is larger than the server is willing or able to process.
URI Too Long
Request URI is longer than the server is willing to interpret.
Unsupported Media Type
The request's media type is not supported by the resource.
Range Not Satisfiable
The Range header requests a portion that cannot be supplied.
Expectation Failed
The expectation given in the Expect header could not be met.
I'm a Teapot
April Fools' joke from RFC 2324. Returned by teapots that cannot brew coffee.
Misdirected Request
Request was directed at a server unable to produce a response for the target URI.
Unprocessable Content
Request was well-formed but had semantic errors. Common for validation failures.
Locked
WebDAV: the resource being accessed is locked.
Failed Dependency
WebDAV: the request failed because it depended on another request that failed.
Too Early
Server is unwilling to risk processing a request that might be replayed.
Upgrade Required
Client must switch to a different protocol given in the Upgrade header.
Precondition Required
Server requires the request to be conditional (e.g. If-Match) to avoid lost updates.
Too Many Requests
Client has sent too many requests in a given time. Use Retry-After header.
Request Header Fields Too Large
Server refuses to process the request because headers are too large.
Unavailable For Legal Reasons
Resource is unavailable due to a legal demand (e.g. censorship, takedown).
5xx Server Error
Server failed to fulfill an apparently valid request.
Internal Server Error
Generic error: the server encountered an unexpected condition.
Not Implemented
Server does not support the functionality required to fulfill the request.
Bad Gateway
Server, acting as a gateway, received an invalid response from an upstream server.
Service Unavailable
Server is temporarily unable to handle the request (overload or maintenance).
Gateway Timeout
Gateway did not receive a timely response from the upstream server.
HTTP Version Not Supported
Server does not support the HTTP protocol version used in the request.
Variant Also Negotiates
Transparent content negotiation results in a circular reference.
Insufficient Storage
WebDAV: server cannot store the representation needed to complete the request.
Loop Detected
WebDAV: server detected an infinite loop while processing the request.
Not Extended
Further extensions to the request are required for the server to fulfill it.
Network Authentication Required
Client needs to authenticate to gain network access (e.g. captive portal).
About HTTP Status Codes
HTTP Status Codes is a searchable reference for every status code in the HTTP standard — 1xx informational, 2xx success, 3xx redirection, 4xx client error, 5xx server error — plus the common non-standard codes that real servers return (`418 I'm a teapot`, `444 No Response`, `499 Client Closed Request`). Each entry has a one-line description, a longer explanation of when to send it, and a link to the relevant RFC section so you can jump to the canonical definition.
Reach for it whenever you are debugging or designing an API: deciding between `400` and `422` for a validation failure, working out whether `301` or `308` is the right redirect, or looking up what `425 Too Early` actually means before merging a feature that returns it. The reference is offline — every code is bundled into the page, so no network request is needed to look up the meaning of a code that just appeared in your logs.
Examples
search: 422422 Unprocessable Content
— The request was well-formed but had semantic errors (validation failed).
— RFC 9110 §15.5.21Each entry includes a description, a longer rationale, and a deep link to the RFC. Search by number or by keyword ("redirect", "validation", "forbidden").
Frequently asked questions
Which RFCs do the descriptions follow?
RFC 9110 (HTTP Semantics, the consolidated definition that supersedes RFC 7231), RFC 9111 (Caching), and the WebDAV / RESTful extensions where applicable. Older codes that originated in RFC 2616 or 7231 are still cited for historical context.
Should I use 400 or 422 for validation errors?
Both are widely used. RFC 9110 says `400 Bad Request` covers any malformed request; `422 Unprocessable Content` is more specific — the request *parses* fine but the contents fail semantic validation. Use 422 if you want clients to distinguish parse errors from validation errors; otherwise 400 is fine.
What is the difference between 301, 302, 307, and 308?
301 / 308 are *permanent*; 302 / 307 are *temporary*. 301 / 302 may change the request method (POST → GET) on follow; 307 / 308 preserve the method. Modern recommendation: 308 for permanent redirects (preserves method), 307 for temporary, never 301 or 302 unless you must support ancient clients.
Why does the reference include non-standard codes?
Because real servers return them. `418 I'm a teapot` is a joke that became canonical; `444 No Response` is Nginx-specific; `499 Client Closed Request` is widely emitted by proxies. Knowing what a non-standard code means is more useful than pretending it is not there.