HTTP Status Codes Reference
Look up any HTTP status code's meaning, common causes, whether to retry, and its defining RFC section — searchable and filterable by class.
Runs in your browser; nothing is uploaded.
Runs in your browser; filtering never leaves the page.
Status codes
50 of 50 status codes
100 Continue
The server has received the request headers and the client should proceed to send the request body.
Common causes: Sent automatically by the server after an `Expect: 100-continue` request header, before the client uploads a large body.
Retry: Not applicable — this is an interim response; the client just continues sending.
RFC reference101 Switching Protocols
The server is switching to the protocol requested by the client via the `Upgrade` header, e.g. to WebSockets.
Common causes: A successful WebSockets or HTTP/2 upgrade handshake.
Retry: Not applicable — the connection continues on the new protocol.
RFC reference103 Early Hints
Preliminary headers (e.g. `Link` preload hints) sent before the final response, so the client can start fetching resources early.
Common causes: A server optimising page load by hinting at CSS/JS/font resources before the main response is ready.
Retry: Not applicable — the client waits for the final response that follows.
RFC reference200 OK
The request succeeded, and the response body (if any) contains the requested representation.
Common causes: The default success response for GET, and often for POST/PUT when the response carries a representation.
Retry: Not applicable — the request already succeeded.
RFC reference201 Created
The request succeeded and a new resource was created; the `Location` header usually points to it.
Common causes: A successful POST to a collection endpoint (e.g. creating a new user or order).
Retry: Not applicable — retrying a Created response's originating POST may create a duplicate resource.
RFC reference202 Accepted
The request was accepted for processing, but processing isn't complete yet.
Common causes: Asynchronous/queued work — a webhook receiver, a batch job, a long-running export.
Retry: Not applicable — poll the status endpoint the API documents instead of retrying the original request.
RFC reference204 No Content
The request succeeded and there is no response body to return.
Common causes: A successful DELETE, or a PUT/PATCH that doesn't need to echo the updated resource back.
Retry: Not applicable — the request already succeeded.
RFC reference206 Partial Content
The server is returning only part of the resource, as requested by a `Range` header.
Common causes: Resumable downloads, video/audio streaming, or a client fetching a byte range of a large file.
Retry: Not applicable — this is the expected response to a range request.
RFC reference301 Moved Permanently
The resource has permanently moved to a new URL, given in `Location`.
Common causes: A URL restructuring or domain migration, with a permanent redirect left behind for old links.
Retry: Update the stored/bookmarked URL to the new `Location` and use that going forward.
RFC reference302 Found
The resource is temporarily at a different URL; the original URL should keep being used for future requests.
Common causes: Temporary redirects — e.g. redirecting to a login page, or load-balancing to a mirror.
Retry: Follow the `Location` header for this request only; don't update stored links.
RFC reference303 See Other
The response to the request can be found at another URL, and should be retrieved with GET regardless of the original method.
Common causes: The classic "POST then redirect to GET" pattern after a form submission.
Retry: Re-request the `Location` URL with GET.
RFC reference304 Not Modified
The client's cached copy (validated via `If-None-Match` / `If-Modified-Since`) is still current; no body is sent.
Common causes: A conditional GET where the resource's ETag or Last-Modified hasn't changed since the client's cached copy.
Retry: Not applicable — use the cached response; this isn't an error.
RFC reference307 Temporary Redirect
Like 302, but the method and body must be preserved on the redirected request.
Common causes: A temporary redirect for a non-GET request (e.g. a POST) where the method must not change.
Retry: Re-request the `Location` URL with the same method and body.
RFC reference308 Permanent Redirect
Like 301, but the method and body must be preserved on the redirected request.
Common causes: A permanent redirect for a non-GET request, or an API deliberately keeping the method unchanged.
Retry: Update the stored URL and re-request it with the same method and body.
RFC reference400 Bad Request
The server couldn't understand the request due to malformed syntax, invalid parameters, or a body it couldn't parse.
Common causes: Invalid JSON, a missing required field, a parameter of the wrong type, or a malformed query string.
Retry: Fix the request body/parameters before retrying — retrying unchanged will fail again.
RFC reference401 Unauthorized
The request lacks valid authentication credentials for the target resource.
Common causes: A missing, expired, or malformed API key/token/session cookie; or none was sent at all.
Retry: Authenticate (or refresh the credential) and retry with valid credentials.
RFC reference403 Forbidden
The server understood the request but refuses to authorize it — regardless of whether valid credentials were sent; the reason can be unrelated to credentials entirely.
Common causes: Insufficient permissions/role, an IP allowlist block, a disabled account, or a resource-level access rule.
Retry: Retrying unchanged won't help — a different account, elevated permission, or a different source IP is needed.
RFC reference404 Not Found
The server has no current representation for the target resource, or won't disclose that one exists.
Common causes: A mistyped URL, a deleted or never-existing resource, or an ID that belongs to a different account.
Retry: Confirm the URL/ID is correct; retrying the same request won't produce a different result.
RFC reference405 Method Not Allowed
The method used (GET, POST, DELETE, …) isn't supported for this resource.
Common causes: Calling a read-only endpoint with POST, or an endpoint that only accepts POST with GET.
Retry: Check the API's documented allowed methods (often listed in the response's `Allow` header) and use one of those.
RFC reference406 Not Acceptable
The server can't produce a response matching the `Accept` header's requested content types.
Common causes: Requesting a format (e.g. `Accept: application/xml`) the API doesn't support.
Retry: Adjust the `Accept` header to a format the API actually offers, then retry.
RFC reference407 Proxy Authentication Required
Like 401, but authentication is required by an intermediate proxy, not the origin server.
Common causes: A corporate/ISP forward proxy that requires its own login before it will forward the request.
Retry: Authenticate with the proxy (per its `Proxy-Authenticate` header) and retry.
RFC reference408 Request Timeout
The server timed out waiting for the request to complete.
Common causes: A slow client connection, or a server closing idle keep-alive connections.
Retry: Safe to retry, ideally with backoff, especially if the request is idempotent.
RFC reference409 Conflict
The request conflicts with the current state of the target resource.
Common causes: A duplicate unique field (e.g. an email already in use), or two concurrent edits to the same record.
Retry: Fetch the current state, resolve the conflict, and retry with an updated request — not the same one.
RFC reference410 Gone
The resource used to exist but has been permanently removed, and won't come back.
Common causes: A deliberately retired endpoint or deleted resource that the server knows will never return.
Retry: Not applicable — unlike 404, this is a deliberate, permanent removal; don't retry or expect it to reappear.
RFC reference411 Length Required
The server requires a `Content-Length` header, which the request omitted.
Common causes: A client streaming a body with chunked transfer encoding to a server that requires a known length.
Retry: Add an explicit `Content-Length` header and retry.
RFC reference412 Precondition Failed
A conditional request header (`If-Match`, `If-Unmodified-Since`, …) didn't match the current resource state.
Common causes: Optimistic-concurrency updates — someone else changed the resource since you last read its ETag.
Retry: Re-fetch the current resource/ETag, then retry the conditional request with the updated value.
RFC reference413 Content Too Large
The request body is larger than the server is willing or able to process.
Common causes: An upload or JSON payload exceeding the API's documented size limit.
Retry: Reduce the payload size (or split it) before retrying — retrying unchanged will fail again.
RFC reference414 URI Too Long
The request-target (URL) is longer than the server is willing to interpret.
Common causes: An excessively long query string, often from encoding a large payload into GET parameters.
Retry: Shorten the URL, or move the data into a POST body, then retry.
RFC reference415 Unsupported Media Type
The request body's format (per `Content-Type`) isn't supported by this endpoint.
Common causes: Sending `application/xml` to an endpoint that only accepts `application/json`, or vice versa.
Retry: Set `Content-Type` to a format the endpoint documents, and encode the body accordingly, then retry.
RFC reference416 Range Not Satisfiable
The `Range` header's requested byte range doesn't fit the resource's actual size.
Common causes: Requesting bytes past the end of a file, often after the file changed size on the server.
Retry: Confirm the resource's current size (e.g. via a HEAD request) and request a valid range.
RFC reference417 Expectation Failed
The server can't meet the requirement given in the request's `Expect` header.
Common causes: A client sending `Expect: 100-continue` to a server or proxy that doesn't support it.
Retry: Retry without the `Expect` header.
RFC reference418 I'm a teapot
An April Fools' RFC 2324 joke status; some servers use it deliberately to block obvious bot traffic.
Common causes: A server (often intentionally) refusing to "brew coffee" for automated or unwanted requests.
Retry: Not applicable — treat it the way the specific server's documentation says to (often as a deliberate block).
RFC reference421 Misdirected Request
The request was routed to a server that can't produce a response for the scheme/authority in the request line.
Common causes: HTTP/2 connection reuse across hostnames sharing a certificate, sent to the wrong backend.
Retry: Retry the request on a new connection to the correct origin.
RFC reference422 Unprocessable Content
The request is well-formed (valid JSON, correct `Content-Type`) but semantically invalid.
Common causes: A validation failure: a field that's the right type but the wrong value, or fails a business rule.
Retry: Fix the data per the error details before retrying — the request syntax was fine, the content wasn't.
RFC reference423 Locked
The resource being accessed is locked (WebDAV).
Common causes: A WebDAV client editing a file another client currently has locked.
Retry: Wait for the lock to be released, or retry once it is, then retry the request.
RFC reference425 Too Early
The server is unwilling to risk processing a request that might be replayed (sent over TLS 1.3 early data).
Common causes: A client sending a request as TLS 1.3 "early data" that carries replay risk (e.g. a non-idempotent request).
Retry: Retry the same request once the full TLS handshake has completed (not as early data).
RFC reference426 Upgrade Required
The server refuses to continue on the current protocol and requires the client to upgrade (e.g. to TLS or HTTP/2).
Common causes: A server that only accepts a newer protocol version, signalled via the `Upgrade` header.
Retry: Retry using the protocol named in the `Upgrade` response header.
RFC reference428 Precondition Required
The server requires the request to be conditional (carry an `If-Match`/`If-Unmodified-Since` header), and it wasn't.
Common causes: An API enforcing optimistic concurrency control on every write.
Retry: Fetch the resource's current ETag, add the appropriate conditional header, and retry.
RFC reference429 Too Many Requests
The client has sent too many requests in a given time window (rate limiting).
Common causes: Exceeding an API's documented requests-per-minute/hour limit.
Retry: Retry after the duration in the `Retry-After` header (if present), with backoff; don't retry immediately.
RFC reference431 Request Header Fields Too Large
The request's header fields are too large for the server to process.
Common causes: An oversized cookie, an excessively long `Authorization` header, or too many headers.
Retry: Shrink the offending header(s) (e.g. a bloated cookie) and retry.
RFC reference451 Unavailable For Legal Reasons
The resource is unavailable due to a legal demand (e.g. a government-mandated content block).
Common causes: Content blocked in a specific jurisdiction by court order or government request.
Retry: Not applicable — this is a deliberate legal restriction, not a transient failure.
RFC reference500 Internal Server Error
The server encountered an unexpected condition and couldn't fulfil the request.
Common causes: An unhandled exception, a bug, or a misconfiguration on the server — this is on the server, not the client.
Retry: Safe to retry once or twice with backoff; if it persists, it needs the server operator's attention.
RFC reference501 Not Implemented
The server doesn't support the functionality required to fulfil the request (e.g. an unrecognised method).
Common causes: Calling a method the server's framework hasn't implemented for that route.
Retry: Not applicable — retrying the same request won't add the missing functionality.
RFC reference502 Bad Gateway
A server acting as a gateway or proxy received an invalid response from the upstream server.
Common causes: An application server crashing, restarting, or timing out behind a reverse proxy/load balancer.
Retry: Safe to retry with backoff — often transient, especially during a deploy or upstream restart.
RFC reference503 Service Unavailable
The server is temporarily unable to handle the request (overloaded or down for maintenance).
Common causes: Planned maintenance, an overloaded backend, or an autoscaler still bringing up capacity.
Retry: Retry after the duration in the `Retry-After` header (if present), with backoff.
RFC reference504 Gateway Timeout
A server acting as a gateway or proxy didn't receive a timely response from the upstream server.
Common causes: A slow database query, a hung upstream service, or a proxy timeout shorter than the backend needs.
Retry: Safe to retry with backoff; if it's consistent, the upstream operation itself may need to be faster.
RFC reference505 HTTP Version Not Supported
The server doesn't support the HTTP protocol version used in the request.
Common causes: A very old or very new HTTP version the server's stack doesn't handle.
Retry: Retry using a widely-supported HTTP version (HTTP/1.1 or HTTP/2).
RFC reference507 Insufficient Storage
The server can't store the representation needed to complete the request (WebDAV).
Common causes: A WebDAV server that has run out of disk space or storage quota.
Retry: Free up space/quota on the server side before retrying; the client can't fix this alone.
RFC reference508 Loop Detected
The server terminated an operation because it detected an infinite loop (WebDAV).
Common causes: A WebDAV `Depth: infinity` request that would otherwise recurse forever.
Retry: Not applicable without changing the request — retrying identically will loop again.
RFC reference511 Network Authentication Required
The client needs to authenticate to gain network access (e.g. a captive portal).
Common causes: Public Wi-Fi or hotel/airport networks that intercept traffic until you log in through a captive portal.
Retry: Complete the network's authentication/portal flow, then retry the original request.
RFC reference
How to use it
How to use this reference
Search by code (404), name (not found), or a keyword from the description (retry, timeout), or filter by class using the 1xx–5xx chips.
Each entry gives the code's official meaning per the HTTP semantics RFC, the situations that most commonly produce it, whether it's worth retrying the request (and how), and a link to the specific RFC section that defines it — so you can check the primary source rather than take a summary's word for it.
The three-digit code determines its class: 1xx are informational, 2xx mean success, 3xx are redirects, 4xx mean the client's request needs to change, and 5xx mean the server itself failed. Knowing the class alone often tells you who needs to act — the caller (4xx) or the server operator (5xx) — before you even read the specific code's meaning.
Frequently asked questions
What's the real difference between a 4xx and a 5xx error?
A 4xx means the request itself was the problem — bad syntax, missing auth, invalid data, wrong permissions — and resending the same request will fail again until you change it. A 5xx means the server failed while trying to handle an otherwise valid request, so it's often (not always) worth retrying unchanged.
Should I automatically retry every failed request?
Only retry when it can help: most 5xx codes and 429 (with backoff) are good candidates, especially for idempotent requests (GET, or a PUT/DELETE with the same effect every time). Retrying a 4xx unchanged, or retrying a non-idempotent POST blindly, can make things worse — e.g. creating a duplicate order.
What does the Retry-After header do?
It tells the client how long to wait before trying again, either as a number of seconds or an HTTP date. It commonly appears on 429 (Too Many Requests) and 503 (Service Unavailable) responses, and a well-behaved client should honour it rather than retrying immediately.
Why do 404 and 410 both mean "not found", and does the difference matter?
404 means the server has no representation for that resource right now (it may have never existed, or might return later); 410 means the server knows the resource is gone permanently and isn't coming back. Search engines and caches treat a confirmed 410 as more final than a 404.
Is 418 "I'm a teapot" a real status code?
It comes from RFC 2324, an April Fools' RFC from 1998 (the "Hyper Text Coffee Pot Control Protocol"). RFC 9110 §15.5.19 formally reserves 418 as unused in the standard HTTP status code registry, but a handful of real servers and tools use it deliberately anyway — often to block or flag automated traffic in a memorable way.