HTTP status codes
Every HTTP status code from 100 to 511, with its official name, what it means, when to use it and the RFC that defines it. Search by number or word.
- 100
Continue
The server got the headers and the client may send the body.
When to use it: Reply to Expect: 100-continue before uploading a large body.
RFC 9110
- 101
Switching Protocols
The server agrees to switch to the protocol named in the Upgrade header.
When to use it: When opening a WebSocket.
RFC 9110
- 102
Processing
WebDAV: the request is still being processed and there is no final answer yet. Deprecated today.
RFC 2518
- 103
Early Hints
Sends Link headers early so the browser can preload resources while the response is being prepared.
RFC 8297
- 200
OK
The request succeeded and the response carries the result.
RFC 9110
- 201
Created
A new resource was created. The Location header usually gives its URL.
When to use it: After a POST that creates something.
RFC 9110
- 202
Accepted
The request was accepted but will be processed later.
When to use it: Queued or asynchronous jobs.
RFC 9110
- 203
Non-Authoritative Information
Success, but a proxy has changed the origin server response.
RFC 9110
- 204
No Content
Success, with no body in the response.
When to use it: A DELETE or PUT that does not need to return anything.
RFC 9110
- 205
Reset Content
Success; the client should reset the form or view that sent the request.
RFC 9110
- 206
Partial Content
Returns only the part requested with the Range header.
When to use it: Resuming downloads and video streaming.
RFC 9110
- 207
Multi-Status
WebDAV: the XML body carries a separate status for each resource involved.
RFC 4918
- 208
Already Reported
WebDAV: this resource was already listed earlier in the same 207 response.
RFC 5842
- 226
IM Used
The response is the result of applying an instance manipulation (delta encoding) to the resource.
RFC 3229
- 300
Multiple Choices
The resource has several representations and the client may choose one.
RFC 9110
- 301
Moved Permanently
The resource has a new permanent URL, given in Location. Search engines carry the ranking over.
When to use it: Domain or URL structure changes. Some clients turn POST into GET: if that matters, use 308.
RFC 9110
- 302
Found
The resource is temporarily at another URL, given in Location.
When to use it: Temporary redirects. To keep the method, use 307.
RFC 9110
- 303
See Other
The result is at another URL that must be fetched with GET.
When to use it: After a form submission (POST/redirect/GET pattern).
RFC 9110
- 304
Not Modified
The resource has not changed since the client cached copy, so it is not sent again.
When to use it: Reply to If-None-Match or If-Modified-Since.
RFC 9110
- 305
Use Proxy Historic
Obsolete: asked to repeat the request through a proxy. Browsers ignore it for security reasons.
RFC 9110
- 306
(Unused) Unused
Used in an old draft (“Switch Proxy”) and reserved today.
RFC 9110
- 307
Temporary Redirect
Like 302, but the client must repeat the request with the same method and body.
RFC 9110
- 308
Permanent Redirect
Like 301, but keeping the method and the body.
When to use it: Moving an API for good.
RFC 9110
- 400
Bad Request
The request is malformed: invalid syntax, parameters or body.
RFC 9110
- 401
Unauthorized
Authentication is missing or the credentials are wrong. It must come with a WWW-Authenticate header.
When to use it: No session or an expired token. If the user is authenticated but not allowed, use 403.
RFC 9110
- 402
Payment Required
Reserved for future payment use. Some APIs use it when credit or a subscription runs out.
RFC 9110
- 403
Forbidden
The server understands the request but refuses it. Authenticating again will not help.
RFC 9110
- 404
Not Found
There is nothing at that URL, or the server would rather not say it exists.
RFC 9110
- 405
Method Not Allowed
The resource exists but does not accept that method. The Allow header lists the ones it does.
RFC 9110
- 406
Not Acceptable
No representation matches the client Accept headers.
RFC 9110
- 407
Proxy Authentication Required
Like 401, but the proxy is the one asking for credentials.
RFC 9110
- 408
Request Timeout
The client took too long to send the full request and the server closed the connection.
RFC 9110
- 409
Conflict
The request conflicts with the current state of the resource.
When to use it: Concurrent edits or a username that is already taken.
RFC 9110
- 410
Gone
The resource existed and has been removed for good, with no new address.
RFC 9110
- 411
Length Required
The server requires a Content-Length header.
RFC 9110
- 412
Precondition Failed
A condition in the request is not met, such as If-Match with an old ETag.
RFC 9110
- 413
Content Too Large
The body is larger than the server accepts. It used to be called Payload Too Large.
RFC 9110
- 414
URI Too Long
The URL is longer than the server can process.
RFC 9110
- 415
Unsupported Media Type
The server does not accept the body format (Content-Type or Content-Encoding).
RFC 9110
- 416
Range Not Satisfiable
The range asked for with Range falls outside the resource size.
RFC 9110
- 417
Expectation Failed
The server cannot meet what the Expect header asks for.
RFC 9110
- 418
I'm a teapot Joke
An April Fools joke from 1998: a teapot refuses to brew coffee. RFC 9110 reserves it so nobody reuses it.
RFC 2324
- 421
Misdirected Request
The request reached a server that cannot answer for that host, for example when reusing an HTTP/2 connection.
RFC 9110
- 422
Unprocessable Content
The syntax is fine, but the data fails validation.
When to use it: Validation errors in an API (an empty email, an impossible date).
RFC 9110
- 423
Locked
WebDAV: the resource is locked by another client.
RFC 4918
- 424
Failed Dependency
WebDAV: the action failed because another one it depended on failed.
RFC 4918
- 425
Too Early
The server will not process a request sent in TLS 1.3 early data, because it could be replayed.
RFC 8470
- 426
Upgrade Required
The client must switch to another protocol, given in the Upgrade header.
RFC 9110
- 428
Precondition Required
The server requires conditional requests (If-Match) so changes are not overwritten.
RFC 6585
- 429
Too Many Requests
The client went over the rate limit. Retry-After says how long to wait.
When to use it: API rate limiting.
RFC 6585
- 431
Request Header Fields Too Large
The headers, or one of them, are too large. It often happens with huge cookies.
RFC 6585
- 451
Unavailable For Legal Reasons
The resource is withheld because of a legal demand, such as censorship or a lawsuit. The number nods to Fahrenheit 451.
RFC 7725
- 500
Internal Server Error
Something failed on the server and there is no more specific code.
RFC 9110
- 501
Not Implemented
The server does not support the functionality needed, for example a method it does not know.
RFC 9110
- 502
Bad Gateway
A proxy or gateway got an invalid response from the server behind it.
RFC 9110
- 503
Service Unavailable
The server cannot handle the request right now, because of overload or maintenance. Retry-After may say when to come back.
RFC 9110
- 504
Gateway Timeout
A proxy or gateway did not get a timely response from the server behind it.
RFC 9110
- 505
HTTP Version Not Supported
The server does not support the HTTP version of the request.
RFC 9110
- 506
Variant Also Negotiates
Content negotiation misconfiguration: the chosen variant negotiates again.
RFC 2295
- 507
Insufficient Storage
WebDAV: the server has no room to store what is asked.
RFC 4918
- 508
Loop Detected
WebDAV: the server found an infinite loop while processing the request.
RFC 5842
- 510
Not Extended Historic
Historic: the request needed extensions the server does not support.
RFC 2774
- 511
Network Authentication Required
You must log in to the network to reach the internet, as on hotel or airport WiFi.
RFC 6585
How it works
How it works
Every HTTP response starts with a three-digit code that sums up what happened. The first digit gives the class: 1xx informational, 2xx success, 3xx redirection, 4xx client errors and 5xx server errors. Here you have every code in the IANA registry with its official name, a short explanation, when it is worth using and the RFC that defines it.
Search by number (type 40 to see 400 to 409) or by words in English or Spanish, without worrying about accents. You can also filter by class and link straight to a code with #404 at the end of the address.
The ones people mix up
401 is “I do not know who you are” and 403 is “I know who you are and you cannot come in”. 400 is a malformed request and 422 a well-formed request whose data fails validation. For redirects, 307 and 308 keep the method and body, while with 301 and 302 many clients turn a POST into a GET. 418 is a 1998 joke that RFC 9110 reserves so nobody reuses it.
FAQ
What is the difference between 401 and 403?
401 means you are not identified or your credentials are wrong: logging in again may fix it. 403 means the server knows who you are and still will not let you in.
301 or 308? 302 or 307?
All four redirect. 307 and 308 require repeating the request with the same method and body; with 301 and 302 many clients turn a POST into a GET. For permanent moves use 301 or 308; for temporary ones, 302 or 307.