61 codes
The initial part of the request was received and the client should continue sending the body.
When: When a client sends an Expect: 100-continue header before uploading a large body and the server is willing to accept it.
The server agrees to switch to the protocol the client asked for in the Upgrade header.
When: During a WebSocket handshake, or when upgrading from HTTP/1.1 to HTTP/2 over cleartext.
The server has received and is processing the request, but no response is available yet (WebDAV).
When: On long-running WebDAV operations, to keep the client from timing out while work continues.
Preliminary headers (such as preload/preconnect Link headers) sent before the final response.
When: When a server wants the browser to start fetching critical assets before the full page response is ready.
Standard success response. The body contains the requested result.
When: On any successful GET, or a PUT/POST/DELETE that returns a representation of the result.
The request succeeded and a new resource was created.
When: After a POST/PUT that creates a record; the Location header points to the new resource.
The request was accepted for processing, but processing is not complete.
When: For asynchronous/queued work where the result will be ready later (batch jobs, background tasks).
The returned metadata came from a copy/transforming proxy rather than the origin server.
When: When a proxy modifies the origin's response headers before returning them.
Success, but there is no body to return.
When: After a successful DELETE, or a PUT/PATCH where the client does not need the updated body.
Success; the client should reset the document view that sent the request.
When: After a form submission where the server wants the client to clear the form for a new entry.
The server is delivering only part of the resource (a byte range).
When: On range requests — video seeking, resumable downloads — when the client sends a Range header.
Conveys multiple independent status codes for a batch operation (WebDAV).
When: On WebDAV requests that act on several resources, each with its own result.
Members of a binding were already enumerated and are not repeated (WebDAV).
When: Inside a 207 Multi-Status response, to avoid repeating already-listed resources.
The server fulfilled the request using instance manipulations applied to the current instance.
When: On delta-encoding requests where only the differences from a known version are returned.
The resource has several representations and the client (or user) should pick one.
When: Rarely; when content negotiation cannot pick a single best response automatically.
The resource has a new permanent URL; update links and pass on ranking.
When: After a permanent move — domain change, http→https, trailing-slash normalization. Search engines transfer authority.
The resource is temporarily at a different URL; keep using the original.
When: On temporary redirects, e.g. post-login bounce. Note: most clients change the method to GET (use 307 to preserve it).
Fetch the result from another URL using a GET request.
When: After a POST (Post/Redirect/Get pattern) so a refresh does not re-submit the form.
The cached copy is still valid; no body is sent.
When: On a conditional request (If-None-Match / If-Modified-Since) when the resource hasn't changed — saves bandwidth.
Like 302, but the HTTP method and body must not change.
When: On a temporary redirect where a POST must stay a POST to the new URL.
Like 301, but the HTTP method and body must not change.
When: On a permanent redirect that must preserve POST/PUT (e.g. an API endpoint that moved).
The server could not understand the request due to malformed syntax or invalid framing.
When: On invalid JSON, a missing required field, or a malformed query string. Fix the request and retry.
Authentication is required and has failed or not been provided.
When: When a token/credential is missing, expired, or invalid. The response carries a WWW-Authenticate header.
Reserved for future use; increasingly used for billing/quota gates.
When: On some APIs when a paid plan or quota is exhausted (Stripe, GitHub, etc.).
The server understood the request but refuses to authorize it.
When: When you are authenticated but lack permission, or the server hides a resource from you. Re-auth won't help.
The resource could not be found at this URL.
When: On a wrong/deleted URL, a typo, or when a server hides a resource it doesn't want to reveal exists.
The HTTP method is not supported for this resource.
When: When you POST to a read-only endpoint, or DELETE something that only allows GET. The Allow header lists valid methods.
No representation matches the client's Accept headers.
When: When the client demands a content type/language the server cannot produce.
The client must authenticate with a proxy first.
When: Behind a corporate proxy that requires credentials before forwarding the request.
The server timed out waiting for the request to be sent.
When: When the client opened a connection but was too slow to send the full request.
The request conflicts with the current state of the resource.
When: On a version/edit conflict, a duplicate unique key, or concurrent updates (optimistic locking).
The resource was intentionally removed and will not come back.
When: When content is permanently deleted and you want crawlers to drop it (stronger signal than 404).
The server requires a Content-Length header.
When: When a request with a body omits Content-Length and the server won't accept chunked transfer.
A precondition in the request headers evaluated to false.
When: On a conditional write (If-Match / If-Unmodified-Since) when the resource changed underneath you.
The request body is larger than the server is willing to process.
When: On oversized file uploads or request bodies exceeding a configured limit.
The request URI is longer than the server will interpret.
When: When too much data is crammed into the query string (use a POST body instead).
The request body is in a format the resource does not support.
When: When you send XML to a JSON-only endpoint, or omit/mismatch the Content-Type header.
The requested byte range cannot be served.
When: On a Range request whose start is beyond the end of the file.
The expectation in the Expect header cannot be met.
When: When the server cannot honor an Expect: 100-continue request.
An April Fools' joke code (RFC 2324) — the server refuses to brew coffee.
When: As an easter egg; some APIs return it deliberately for fun or to signal a blocked/unsupported action.
The request was sent to a server that cannot produce a response for it.
When: On HTTP/2 connection coalescing when a request lands on the wrong origin.
The request was well-formed but is semantically invalid.
When: On validation failures — correct JSON but a value fails business rules (most common in REST APIs).
The resource being accessed is locked (WebDAV).
When: When another client holds a WebDAV lock on the resource.
The request failed because a dependent request failed (WebDAV).
When: Inside a batch where an earlier operation it relied on already failed.
The server is unwilling to process a request that might be replayed.
When: On TLS 1.3 early-data (0-RTT) requests the server won't risk replaying.
The client must switch to a different protocol.
When: When the server insists on TLS or a newer protocol via the Upgrade header.
The server requires the request to be conditional.
When: To prevent the lost-update problem — the server demands an If-Match header on writes.
The client has sent too many requests in a given time (rate limiting).
When: When you hit an API rate limit. Honor the Retry-After header and back off before retrying.
Headers are too large for the server to process.
When: On bloated cookies or an oversized Authorization/Referer header.
The resource is blocked for legal reasons (e.g. censorship, DMCA).
When: When content is geo-blocked or removed due to a legal demand.
A generic, unexpected server-side failure.
When: On an unhandled exception or crash. The request may be fine; retrying sometimes helps, but it's a server bug.
The server does not support the functionality required to fulfil the request.
When: When you use a method the server doesn't recognize or hasn't implemented yet.
A gateway/proxy received an invalid response from an upstream server.
When: When a reverse proxy (nginx, a load balancer) can't get a valid reply from the app behind it.
The server is temporarily overloaded or down for maintenance.
When: During deploys, maintenance windows, or overload. Often carries a Retry-After header.
A gateway/proxy did not get a timely response from an upstream server.
When: When the backend is too slow and the proxy gives up waiting (long queries, hung services).
The server does not support the HTTP protocol version used in the request.
When: When a client speaks an HTTP version the server refuses.
A content-negotiation configuration error on the server.
When: On a misconfigured server where transparent negotiation loops.
The server cannot store the representation needed to complete the request (WebDAV).
When: When a WebDAV server is out of disk/quota for the write.
The server detected an infinite loop while processing (WebDAV).
When: On a WebDAV operation that would recurse forever.
Further extensions to the request are required for the server to fulfil it.
When: Rarely; when a required HTTP extension is missing from the request.
The client must authenticate to gain network access.
When: Behind a captive portal (airport/hotel Wi-Fi) before you've signed in.
Based on the IANA HTTP Status Code Registry and RFC 9110. Runs entirely in your browser — nothing is sent anywhere.
Look up HTTP status codes and their meanings, free. HTTP status codes are three-digit numbers a server returns to describe the result of a request — 200 OK, 404 Not Found, 500 Internal Server Error, and many more, defined in RFC 9110. This reference lists every standard code by class (1xx–5xx) with a clear explanation of what each means and when it's used.
It groups every standard code into its five classes (1xx informational, 2xx success, 3xx redirect, 4xx client error, 5xx server error) with plain-English meanings, so you can resolve an unfamiliar code fast. 100% free, no registration, and complete privacy — everything runs locally in your browser, so your data never touches a server.
Every standard status code with its name and a clear explanation of what it signals.
Organized into 1xx–5xx so you instantly know whether a code is success, redirect, or error.
Find the meaning of a code like 401, 403, or 502 without digging through the spec.
Definitions follow RFC 9110 (and related RFCs), the authoritative HTTP semantics standard.
The first digit sets the class: 1xx informational, 2xx success, 3xx redirection, 4xx client error (the request was wrong), and 5xx server error (the server failed). The class alone tells you who's responsible — the client or the server.
401 Unauthorized means you're not authenticated (no or invalid credentials) — log in. 403 Forbidden means you are authenticated but not allowed to access the resource — credentials won't help.
Both are 5xx gateway errors: 502 Bad Gateway means an upstream server returned an invalid response; 504 Gateway Timeout means an upstream server didn't respond in time. They point at a backend or proxy problem, not the client.
200 OK means the request succeeded at the HTTP level, but an API can still return an application error inside a 200 body. For REST, prefer accurate codes (e.g. 201 Created, 400 Bad Request) over a blanket 200.
The core codes are standardized in RFC 9110 (HTTP Semantics), which superseded RFC 7231; some codes come from related RFCs (e.g. 418 from a joke RFC). This reference follows those standards.
We use cookies for analytics and personalized ads to help keep these tools free. Until you accept, ads stay non-personalized and analytics cookies are off. See our Privacy Policy.