HTTP Status Code Lookup

Used when a client sends Expect: 100-continue before a large upload, so it does not waste bandwidth if the server would reject the request anyway.

Sent in reply to an Upgrade header. After this response the connection speaks the new protocol.

An old WebDAV interim response that keeps the client from timing out. Rarely used today.

Lets a server send Link headers (preload, preconnect) while it is still preparing the page, so the browser can start fetching CSS and fonts sooner.

The standard success response. For GET it carries the resource; for POST it usually carries the result of the action.

Typical reply to a POST that creates something. Include a Location header with the new resource’s URL.

Use for work that happens in the background (queued jobs, batch imports). Often returns a link where the client can check progress.

The payload is a modified copy of the origin server’s response, for example after a transforming proxy.

Common for DELETE, or for PUT and PATCH when the client does not need the updated resource back. The response must not have a body.

Tells the client to clear the input that caused the request, such as a submitted form.

Reply to a Range request, used for resumable downloads and video streaming. Comes with a Content-Range header.

The body is an XML document with a separate status for each item in a batch operation.

Used inside a 207 response to avoid listing the same resource many times.

Part of HTTP delta encoding, which is rarely used.

For example different languages or formats. Rarely used because there is no standard way to choose.

Browsers and search engines update to the new URL in the Location header. Clients may change POST to GET when following it; use 308 to keep the method.

Tip: For SEO, use 301 (or 308) when a page moves for good, and redirect straight to the final URL, not through chains.

A temporary redirect. Search engines keep the original URL. Clients may change POST to GET; use 307 to keep the method.

Used after a POST (for example a form submission) to send the browser to a result page, so refreshing does not resubmit the form.

Reply to a conditional request (If-None-Match or If-Modified-Since). No body is sent, which saves bandwidth.

Deprecated for security reasons; browsers ignore it.

Like 302, but the method and body must not change, so a POST stays a POST.

Like 301, but the method and body must not change. Good for APIs that move.

The request is malformed: invalid JSON, a missing required field, a bad query parameter or an oversized header.

How to fix: Check the request body is valid (try the JSON Validator), the Content-Type matches the body, required fields are present and the URL is correctly encoded.

Despite the name, it means “unauthenticated”: no valid credentials were sent. The response should include a WWW-Authenticate header.

How to fix: Send credentials (for example Authorization: Bearer <token>), check the token has not expired (try the JWT Decoder) and that you are calling the right environment.

Not standardised for general use, but some services return it when an account needs payment or has run out of credit.

The server understood who you are but refuses the action, for example missing permissions, an IP block or a firewall rule.

How to fix: Check the account’s roles or scopes, file and folder permissions on the server, and any WAF, CDN or hotlink protection rules.

The most familiar error: the page or API route does not exist, or the server prefers not to say that it does.

How to fix: Check the URL for typos and the trailing slash, confirm the route exists for that HTTP method, and set up redirects for pages that moved.

For example a POST to a read-only endpoint. The response must include an Allow header listing the methods that work.

How to fix: Use one of the methods in the Allow header, and check that your server or framework route is defined for this method.

Content negotiation failed: nothing matches the client’s Accept, Accept-Language or Accept-Encoding headers.

How to fix: Relax the Accept header (for example Accept: */*) or ask for a format the API supports.

Like 401, but for a proxy between you and the server. Comes with a Proxy-Authenticate header.

The client took too long to send the full request, often on a slow or idle connection.

How to fix: Retry the request; check for slow networks or very large uploads, and raise client or server timeouts if needed.

For example creating something that already exists, or an edit based on an old version.

How to fix: Fetch the latest version, merge the changes and retry, or choose a different unique value.

Stronger than 404: search engines drop the URL faster.

The server refuses requests with a body but no declared length.

How to fix: Send a Content-Length header, or use chunked transfer encoding where allowed.

For example If-Match did not match the current ETag, so an update was refused to avoid overwriting someone else’s change.

Formerly “Payload Too Large”. Common with file uploads.

How to fix: Compress or split the upload, or raise the limit (for example client_max_body_size in nginx, upload_max_filesize in PHP).

Often caused by putting too much data in the query string.

How to fix: Send large data in a POST body instead of the URL.

The Content-Type is not one the endpoint accepts, such as sending form data to a JSON-only API.

How to fix: Set the right Content-Type (for example application/json) and make the body match it.

Reply to a Range request that asks for bytes beyond the end of the resource.

Usually means the server does not support Expect: 100-continue.

From the 1998 Hyper Text Coffee Pot Control Protocol. Some APIs use it playfully to reject requests.

Can happen with HTTP/2 connection reuse across domains that share a certificate.

Popular in APIs for validation errors, for example an email address in the wrong format.

How to fix: Read the error details in the response body and correct the fields it names.

Someone else holds a lock on the file.

Used in batch operations where one step depends on another.

Related to TLS 1.3 early data (0-RTT).

For example the server requires TLS or HTTP/2. Comes with an Upgrade header.

The server wants an If-Match header to prevent lost updates.

Rate limiting. The Retry-After header, if present, says how long to wait.

How to fix: Wait for the Retry-After time, add exponential backoff to retries, cache responses and batch requests where the API allows.

Often caused by very large or too many cookies.

How to fix: Clear cookies for the site, or reduce the size of custom headers and tokens.

Used in nginx configuration to drop unwanted requests.

For example a court order or government censorship. The number is a nod to Fahrenheit 451.

Logged by nginx when the user cancels or the client times out first.

How to fix: Look for slow responses that make clients give up, and check client timeouts.

A generic error when the server hit an unexpected problem, such as an unhandled exception.

How to fix: Check the server error logs; it is usually a bug, a failed database query or a misconfiguration. Clients can retry later.

For example an HTTP method the server does not recognise at all.

Common with nginx, load balancers and CDNs when the application server crashed or returned garbage.

How to fix: Check that the upstream application is running and listening on the expected port, and look at both the proxy and application logs.

Overload or maintenance. A Retry-After header can say when to try again.

How to fix: Retry later; on the server side, scale up, fix crashing workers or end the maintenance mode.

The upstream server took too long, often due to a slow database query or external API call.

How to fix: Speed up the slow request, move long work to a background job, or raise proxy timeouts (for example proxy_read_timeout in nginx).

Rare in practice.

The chosen variant is itself set up to negotiate, creating a loop.

For example a full disk during an upload.

Seen in recursive WebDAV operations; some hosts also use it for resource-limit errors.

From an experimental extension framework; now obsolete.

Used by captive portals, such as hotel or airport Wi-Fi login pages.

A catch-all Cloudflare error, often an empty or invalid response.

How to fix: Check that the origin server is healthy and returns valid HTTP responses.

The origin refused the connection.

How to fix: Make sure the web server is running and that its firewall allows Cloudflare’s IP ranges.

The origin did not complete the TCP handshake in time.

Often a DNS or routing problem.

Cloudflare waited about 100 seconds for the HTTP response.

How to fix: Make the request faster or move long-running work to a background job.

Check the origin’s certificate and TLS settings.

Seen with Cloudflare’s Full (strict) SSL mode when the origin certificate is expired or self-signed.