Code & data · HTTPHTTP status codes
What a response code means, who is at fault — the client or the server — and what to do about it. Search by number, name or meaning; sixty-four codes with practice, not just definitions.
Code reference
search by number, name or meaning — «404», «not found», «rate limit»The server accepted the headers and is ready for the request body. Seen only with clients that send `Expect: 100-continue`.
The client asked to switch protocols and the server agreed. This is how a WebSocket connection starts.
The request is accepted and takes a while. A WebDAV response so the client does not treat the connection as stalled.
A preliminary response with links to resources worth loading before the final response is ready.
The request succeeded and the response carries a body. The ordinary answer behind every page that opens.
A resource was created. `Location` carries its address, which is how it is addressed afterwards.
Locationaddress of the created resourceThe request is accepted but not carried out yet: processing happens in the background and the result is fetched separately.
A successful response, modified by an intermediary — a proxy or transformer rather than the origin server.
Success with no response body. The usual answer to a delete or a save when there is nothing to return.
Success, and the client is asked to clear the form the request came from.
The requested part of a file is returned. This is how resumable downloads and video seeking work.
Content-Rangewhich chunk was returnedThe resource has several representations and the server offers a choice. Rare in practice.
The resource has permanently moved to the address in `Location`. For search engines this transfers the page's weight.
- ·The page address or the domain has changed
- ·A redirect from www to the apex domain or to https is configured
- →Update links to the new address — redirect chains slow loading down
- →Make sure the move is really permanent: undoing a cached 301 is hard
Locationthe new addressA temporary redirect: the resource is currently available elsewhere, but that address is not considered permanent.
- ·A temporary page: maintenance, an A/B test, authentication
- →Do not cache it as permanent and do not move links
- →Use 301 for a permanent move, otherwise search keeps the old address
Locationthe temporary addressAfter processing, the result should be fetched from another address with GET. The classic answer after a form submission.
The resource has not changed since the last request — the client uses its cache. There is no response body.
- →Check `ETag` and `If-None-Match` if the response was unexpected
ETagthe resource version tagLike 302, but the method must be preserved: a POST stays a POST instead of turning into a GET.
Like 301, but the request method is preserved. The right choice when an API moves.
- ·An API move, or a move of an address that receives POST
- →Use 308 instead of 301 where the method matters: older clients turn a POST into a GET on a 301
- →Verify the client really repeats the request with the same method
Locationthe new addressThe server could not understand the request: broken syntax, missing parameters or a body in the wrong format.
- ·Malformed JSON or another body format
- ·A required parameter is missing or has the wrong type
- ·An address that is too long or wrongly encoded
- →Check the body and parameters against the API documentation
- →Check how values in the address are encoded
The server does not know who you are: authentication is required. Despite the name it is about identity, not permissions.
- ·The token is missing, expired or revoked
- ·Wrong login or password
- →Refresh the token and retry
- →Check the `Authorization` header — proxies often drop it
WWW-Authenticatewhich authentication scheme is expectedThe server knows who you are but will not let you proceed. This is about permissions, not sign-in: logging in again will not help.
- ·The role lacks permission for the action or the object
- ·Access is blocked by address, country or firewall rules
- →Check permissions rather than the token: 401 and 403 have different fixes
- →Make sure the object belongs to the current user
There is nothing at the address. The most recognisable code: the page was deleted, the address has a typo, or the link is stale.
- ·A typo in the address or a stale link
- ·The page was deleted or renamed without a redirect
- ·A routing mistake in the application
- →Check the address character by character: an extra slash and letter case matter
- →For a permanently removed resource answer 410 — it is more honest and clearer to search engines
The address exists but does not answer this method: a POST where only GET is expected, for instance.
- →Look at the `Allow` header in the response and take a method from it
Allowthe list of allowed methodsThe server cannot produce a response in a format the client is willing to accept per `Accept`.
Like 401, but it is the proxy between client and server that demands authentication.
The client took too long to send the request and the server closed the connection.
The request conflicts with the current state: a duplicate record, or a stale version in concurrent editing.
- ·A record with this unique field already exists
- ·Someone changed the object between read and write
- →Re-read the current state and retry against it
The resource existed and is permanently gone. Unlike 404 this is a statement: there is nothing to come back to.
The server refuses a request without a declared body length.
A condition from headers like `If-Match` failed — usually a guard against overwriting someone else's changes.
The request is bigger than the server accepts. Most often an upload beyond the limit.
The address exceeded the allowed length: usually a form was sent with GET instead of POST.
The body arrived in a format the server does not accept: `text/plain` instead of `application/json`, say.
A byte range outside the file was requested — for instance a resumed download after the file changed.
The server cannot meet the condition in the `Expect` header.
A joke code from the April Fools' RFC 2324 about coffee pots: a teapot cannot brew coffee. Almost never seen in real APIs.
The request reached a server that cannot answer for this domain.
The syntax is valid but the values are not: an email without an at sign, a negative quantity, a date in the past.
- ·A value fails the API validation rules
- →Read the response body: it usually lists the failing fields
- →Tell it apart from 400 — there the request itself is broken, here only the data
The resource is locked against changes — a WebDAV response.
The action failed because a previous one it depends on failed.
The server refuses a request replayed too early while resuming a TLS connection.
The server requires switching protocols — usually to HTTPS or to a newer HTTP version.
The server requires a conditional request so two clients do not overwrite each other's changes.
The rate limit is exceeded. A common API answer to too-frequent requests from one address or key.
- →Read `Retry-After` and wait that long instead of retrying immediately
- →Add pauses between requests and back off exponentially
Retry-Afterhow long to wait before retryingThe request headers exceeded the server limit — often because cookies grew too large.
Access is blocked for legal reasons: a ban, a court order, a rights holder's demand.
- ·A block demanded by a regulator or a court
- ·A rights holder's takedown demand
- →As a visitor, look for the original source: the content is closed by a decision, not by technology
- →As a site owner, answer with 451 rather than 403 or 404: the code exists so that the block is visible
The server crashed while handling a valid request. Nothing to fix on the client side — look in the server logs.
- ·An unhandled exception in the code
- ·A configuration error or an unreachable database
- →Read the server logs: the response body rarely explains anything
- →On someone else's site — retry later; there is nothing to do on the client
The server does not support the method at all — unlike 405, where the method is not allowed for one address.
A proxy or load balancer received an invalid response from the upstream server — or none at all.
- ·The application behind the proxy crashed or is not running
- ·A wrong upstream address or port in the configuration
- →Check whether the application answers directly, bypassing the proxy
- →Read the proxy logs: they show which upstream it called
The server temporarily cannot handle the request: overload or planned maintenance. Temporary by definition.
- ·Maintenance or a restart
- ·Overload: more requests than the server can take
- →Retry later, guided by `Retry-After`
Retry-Afterwhen to try againThe proxy did not get a response from the upstream server within the timeout.
- ·The backend answers slower than the proxy timeout
- ·A heavy request: a report, an export, a long query
- →Measure the backend response time and compare it with the proxy timeout
The server does not support the protocol version used in the request.
A misconfiguration in content negotiation: variants refer to each other in a loop.
The server is out of space to complete the request — a WebDAV response.
The server aborted processing: the request leads to an infinite loop.
The server requires further extensions to the request before fulfilling it.
Network sign-in is required: the typical answer from a public Wi-Fi portal.
An nginx code rather than a standard one: the client disconnected before the server answered. Often means «the tab was closed».
A Cloudflare code: the origin returned a response the proxy could not parse.
A Cloudflare code: the connection to the origin server was refused.
A Cloudflare code: the connection to the origin timed out.
A Cloudflare code: the origin is unreachable — usually a DNS or routing problem.
A Cloudflare code: the connection was established but no response arrived in time.
A Cloudflare code: the TLS handshake with the origin failed.
Confusing pairs: what gets mixed up
301 · 302 · 308
RedirectsPermanent. Carries the page weight over — links are worth updating.
Temporary. Passes no weight; links are left alone.
Permanent and method-preserving: a POST stays a POST.
301 transfers the page's weight to the new address and is cached for a long time; 302 says «here for now» and links should stay; 308 is a 301 that preserves the request method, which is what an API needs.
401 · 403
AccessThe server does not know who you are: no token, or an expired one.
The server knows you and still refuses: the rights are missing.
401 — the server does not know who you are: sign in or refresh the token. 403 — it knows, but refuses: this is about permissions, and signing in again changes nothing.
200 · 204
SuccessSuccess with a body — and the body is what gets read.
Success with no body: check the status code and nothing else.
200 returns a body, 204 is success with none. A client expecting JSON from a 204 breaks while parsing an empty string.
400 · 422
DataThe request itself is broken: syntax, format, a missing parameter.
The request was understood, but the values fail validation.
400 — the request itself is broken: syntax, format, a missing parameter. 422 — the request was understood but the data fails validation: an email without an at sign, a negative quantity.
502 · 504
GatewayThe upstream answered with something unusable — usually it has crashed.
The upstream did not answer in time — alive, but far too slow.
502 — the upstream answered with something unusable or not at all; 504 — the answer did not arrive in time. The first usually means a crashed application, the second a slow one.
About HTTP codes
1xx — informational
Interim2xx — success
All good3xx — redirection
Redirect4xx — client error
The request5xx — server error
The serverWho is at fault
Quick ruleFrequently asked questions
Related tools
Clean and inspect a link
IP and CIDR checker
JWT Decoder
JSON Formatter
Updated