Skip to content

Free tool

HTTP Status Code Lookup

Search any HTTP status code by number or keyword and see what it means, when to return it, and what to watch for with APIs and CDNs.

Runs entirely in your browser. Nothing you enter is sent to a server.

60 codes

  • 100

    Continue

    The server has received the request headers and the client should go ahead and send the body.

    When to use: Used with the Expect: 100-continue header so a client can check before uploading a large body.

  • 101

    Switching Protocols

    The server agrees to switch to the protocol the client asked for in the Upgrade header.

    When to use: Seen when a connection upgrades to WebSocket.

    Note: Reverse proxies and CDNs must be configured to pass the Upgrade headers through.

  • 103

    Early Hints

    An interim response that lets the browser start preloading resources while the server prepares the final response.

    When to use: Send Link headers (preload, preconnect) before a slow page is ready.

    Note: Support depends on the CDN or proxy in front of the origin.

  • 200

    OK

    The request succeeded. The body depends on the method: the resource for GET, the result for POST.

    When to use: The default success code for reads and for actions that return a result.

  • 201

    Created

    The request succeeded and a new resource was created.

    When to use: Return after a successful POST that creates something, with a Location header pointing at the new resource.

  • 202

    Accepted

    The request was accepted for processing but is not finished yet.

    When to use: Use for asynchronous work such as queued jobs; return a link the client can poll for status.

  • 203

    Non-Authoritative Information

    The request succeeded, but a transforming proxy changed the origin’s response.

    When to use: Rare in APIs; set by intermediaries.

  • 204

    No Content

    The request succeeded and there is deliberately no response body.

    When to use: A good fit for a successful DELETE or a PUT/PATCH where the client needs nothing back.

    Note: Do not send a body with a 204.

  • 205

    Reset Content

    The request succeeded and the client should reset the view that sent it, such as clearing a form.

    When to use: Seldom used in practice.

  • 206

    Partial Content

    The server is returning only the byte range the client asked for in a Range header.

    When to use: Resumable downloads and video seeking.

    Note: CDNs rely on range requests to serve large media efficiently.

  • 300

    Multiple Choices

    The resource has several representations and the client may choose one.

    When to use: Rare; most APIs use content negotiation instead.

  • 301

    Moved Permanently

    The resource has a new permanent URL. Clients and search engines should use the new one.

    When to use: Permanent redirects such as http to https or a renamed page.

    Note: Browsers and CDNs may cache it for a long time, so be sure it is permanent. Many clients change POST to GET when following it; use 308 to preserve the method.

  • 302

    Found

    The resource is temporarily at a different URL.

    When to use: Temporary redirects, such as sending a visitor to a login page.

    Note: Many clients change POST to GET when following it; use 307 to preserve the method.

  • 303

    See Other

    The response to the request is at another URL, which should be fetched with GET.

    When to use: Redirect after a POST so a page refresh does not resubmit the form (post/redirect/get).

  • 304

    Not Modified

    The cached copy is still valid, so no body is sent.

    When to use: The answer to a conditional request using If-None-Match or If-Modified-Since.

    Note: This is how ETag and Last-Modified revalidation saves bandwidth at the CDN and browser.

  • 305

    Use Proxy (deprecated)

    Formerly told the client to repeat the request through a given proxy.

    When to use: Do not use. It is deprecated for security reasons.

  • 307

    Temporary Redirect

    Temporary redirect that requires the client to repeat the same method and body at the new URL.

    When to use: Temporary redirects of POST, PUT or DELETE requests.

  • 308

    Permanent Redirect

    Permanent redirect that requires the client to repeat the same method and body at the new URL.

    When to use: Permanent moves of API endpoints that accept POST or PUT.

  • 400

    Bad Request

    The server cannot process the request because it is malformed or invalid.

    When to use: Broken JSON, missing required parameters, wrong types.

    Note: Return a clear error body saying which field is wrong. Use 422 if your API separates syntax errors from validation errors.

  • 401

    Unauthorized

    The request lacks valid authentication credentials.

    When to use: Missing, expired or invalid token or password. Include a WWW-Authenticate header.

    Note: Despite the name, it means “unauthenticated”. Use 403 when the caller is known but not allowed.

  • 402

    Payment Required

    Reserved for future use; the original idea was digital payment schemes.

    When to use: Some APIs use it for exhausted quotas or unpaid plans, but there is no standard behaviour.

  • 403

    Forbidden

    The server understood the request but refuses to authorise it.

    When to use: The caller is authenticated but lacks permission for this resource or action.

    Note: WAFs and CDNs also return 403 when a rule blocks a request. Some APIs return 404 instead to avoid revealing that a resource exists.

  • 404

    Not Found

    The server cannot find the requested resource.

    When to use: Unknown URL or an ID that does not exist.

    Note: It does not say whether the absence is permanent; use 410 for content that is gone for good.

  • 405

    Method Not Allowed

    The method is known but not supported for this resource.

    When to use: For example, DELETE on a read-only endpoint. Include an Allow header listing the valid methods.

  • 406

    Not Acceptable

    The server cannot produce a response matching the client’s Accept headers.

    When to use: Content negotiation failed, such as a request for XML from a JSON-only API.

  • 407

    Proxy Authentication Required

    The client must authenticate with the proxy first.

    When to use: Corporate or forward proxies that need credentials.

  • 408

    Request Timeout

    The server gave up waiting for the client to finish sending the request.

    When to use: Slow or stalled uploads; the client may retry.

  • 409

    Conflict

    The request conflicts with the current state of the resource.

    When to use: Duplicate unique values, edit conflicts, or a state transition that is not allowed.

  • 410

    Gone

    The resource used to exist and has been permanently removed.

    When to use: Deliberately retired content or endpoints; stronger than 404 for search engines.

  • 411

    Length Required

    The server requires a Content-Length header.

    When to use: Servers that refuse requests whose body length is unknown.

  • 412

    Precondition Failed

    A condition in the request headers, such as If-Match, was not met.

    When to use: Optimistic concurrency: the resource changed since the client last read it.

  • 413

    Content Too Large

    The request body is larger than the server is willing to process.

    When to use: Upload limits. Called “Payload Too Large” in older documents.

    Note: Limits are often set by the proxy, load balancer or CDN (for example a client_max_body_size setting) before the application sees the request.

  • 414

    URI Too Long

    The request URL is longer than the server will accept.

    When to use: Very long query strings; move the data into a POST body.

  • 415

    Unsupported Media Type

    The server does not support the format of the request body.

    When to use: A missing or wrong Content-Type, such as sending form data to a JSON-only endpoint.

  • 416

    Range Not Satisfiable

    The requested byte range is outside the resource.

    When to use: A Range request that starts beyond the end of the file.

  • 417

    Expectation Failed

    The server cannot meet the requirement in the Expect header.

    When to use: Rare; a server that does not support Expect: 100-continue.

  • 418

    I’m a teapot

    A joke code from the April Fools’ Hyper Text Coffee Pot Control Protocol (RFC 2324). It is not a real HTTP semantic.

    When to use: Do not rely on it. HTTP reserves the code so that it is not reused.

  • 421

    Misdirected Request

    The request was sent to a server that cannot produce a response for that host.

    When to use: Seen with HTTP/2 connection reuse when a connection is not valid for the requested origin.

  • 422

    Unprocessable Content

    The request is well formed but its content fails validation.

    When to use: Valid JSON with semantically wrong values, such as an invalid email address.

    Note: Many REST APIs prefer 422 for validation errors and 400 for malformed syntax.

  • 425

    Too Early

    The server will not process a request that might be replayed (TLS early data).

    When to use: Protects against replay of 0-RTT requests.

  • 426

    Upgrade Required

    The client must switch to a different protocol to continue.

    When to use: The server requires a newer protocol version; includes an Upgrade header.

  • 428

    Precondition Required

    The server requires the request to be conditional.

    When to use: Force clients to send If-Match so concurrent edits are not overwritten.

  • 429

    Too Many Requests

    The client has sent too many requests in a given time (rate limiting).

    When to use: Rate limits. Send a Retry-After header and let clients back off.

    Note: API gateways, WAFs and CDNs commonly generate this one.

  • 431

    Request Header Fields Too Large

    The request headers, or one header, are too large.

    When to use: Oversized cookies or tokens exceeding server or proxy limits.

  • 451

    Unavailable For Legal Reasons

    Access to the resource is denied for legal reasons.

    When to use: Content blocked by a court order or regulation.

  • 499

    Client Closed Request (nginx)

    Non-standard

    Non-standard nginx code: the client closed the connection before the server replied.

    When to use: It appears in nginx logs, not in responses the client sees.

    Note: Often a sign of client timeouts or an upstream that is too slow.

  • 500

    Internal Server Error

    The server hit an unexpected condition and could not complete the request.

    When to use: The generic catch-all for unhandled server errors.

    Note: Log the cause server side; avoid leaking stack traces to clients.

  • 501

    Not Implemented

    The server does not support the functionality needed for the request.

    When to use: An unrecognised method, or a feature not built yet.

  • 502

    Bad Gateway

    A gateway or proxy received an invalid response from the upstream server.

    When to use: Typically means the application behind a load balancer or reverse proxy crashed or returned garbage.

    Note: Check that the upstream is running and listening on the port the proxy expects.

  • 503

    Service Unavailable

    The server is temporarily unable to handle the request, for example overloaded or down for maintenance.

    When to use: Planned maintenance or load shedding. Send Retry-After when you know when it will recover.

    Note: Health checks and load balancers often use it to take an instance out of rotation.

  • 504

    Gateway Timeout

    A gateway or proxy did not get a timely response from the upstream server.

    When to use: The origin is too slow. Raise the proxy timeout only after finding why the origin is slow.

  • 505

    HTTP Version Not Supported

    The server does not support the HTTP version used in the request.

    When to use: Rare in practice.

  • 511

    Network Authentication Required

    The client must authenticate to gain network access.

    When to use: Captive portals such as hotel or airport Wi-Fi.

  • 520

    Web Server Returned an Unknown Error (Cloudflare)

    Non-standard

    Non-standard Cloudflare code: the origin returned something Cloudflare could not interpret.

    When to use: Check the origin’s logs and responses.

    Note: Cloudflare documents 520 to 526 as its own error codes, not HTTP standards.

  • 521

    Web Server Is Down (Cloudflare)

    Non-standard

    Non-standard Cloudflare code: the origin refused the connection.

    When to use: The origin is offline or a firewall is blocking Cloudflare.

  • 522

    Connection Timed Out (Cloudflare)

    Non-standard

    Non-standard Cloudflare code: Cloudflare could not complete a TCP connection to the origin in time.

    When to use: Origin overloaded, unreachable or blocking Cloudflare IPs.

  • 523

    Origin Is Unreachable (Cloudflare)

    Non-standard

    Non-standard Cloudflare code: Cloudflare could not reach the origin, for example because of a DNS or routing problem.

    When to use: Check DNS records and routing to the origin.

  • 524

    A Timeout Occurred (Cloudflare)

    Non-standard

    Non-standard Cloudflare code: a connection was made, but the origin did not reply before the timeout.

    When to use: Long-running requests; move heavy work to a background job.

  • 525

    SSL Handshake Failed (Cloudflare)

    Non-standard

    Non-standard Cloudflare code: the TLS handshake with the origin failed.

    When to use: Check TLS versions and cipher suites on the origin.

  • 526

    Invalid SSL Certificate (Cloudflare)

    Non-standard

    Non-standard Cloudflare code: Cloudflare could not validate the origin’s TLS certificate.

    When to use: Renew or correct the origin certificate.

How it works

Every HTTP response starts with a three-digit status code. The first digit gives the class: 1xx informational, 2xx success, 3xx redirection, 4xx client error and 5xx server error. The meanings here follow RFC 9110 (HTTP Semantics) and the other RFCs that register further codes.

A handful of widely seen codes that are not part of the standard, from nginx and Cloudflare, are included and clearly marked as non-standard. Type a number, a name or a word like “redirect” or “rate limit” in the search box, or filter by class.

Common uses

  • Choosing the right code when designing a REST or GraphQL API.
  • Working out whether a 5xx comes from your app, the load balancer or the CDN.
  • Setting redirect rules (301, 302, 307, 308) that preserve methods correctly.
  • Writing clear error handling and retry logic: which codes are worth retrying and which are not.

Frequently asked questions

What is the difference between 401 and 403?

401 Unauthorized means the request has no valid credentials, so the client should authenticate and try again. 403 Forbidden means the server knows who you are (or does not care) and still refuses the request. Return 401 when login would help and 403 when it would not.

When should an API use 400 and when 422?

400 Bad Request suits requests that cannot be parsed or are structurally wrong, such as broken JSON. 422 Unprocessable Content suits requests that parse fine but fail validation. Many APIs use 400 for both; what matters most is a consistent, documented choice and a helpful error body.

What is the difference between 301, 302, 307 and 308?

301 and 308 are permanent redirects; 302 and 307 are temporary. 307 and 308 require the client to repeat the same method and body, while some clients change a POST to a GET when following 301 and 302. Use 308 or 307 when the method must be preserved.

Why do I see 502 or 504 errors from a load balancer or CDN?

Both come from an intermediary, not your application. 502 Bad Gateway means the upstream returned an invalid response or the connection failed. 504 Gateway Timeout means the upstream did not answer in time. Check the origin’s health, logs and timeouts.

Are all of these codes official?

Most are registered in the IANA HTTP status code registry and defined in RFC 9110 or the RFCs that extend it. Entries marked non-standard, such as nginx 499 and Cloudflare 520 to 526, are conventions of specific products, so check that product’s documentation.

All free tools

Need something built?

Need help with your cloud or software?

These tools are free to use. If you need cloud and DevOps, web or mobile development, CRM integrations or managed IT support, tell us what you are working on.