HTTP Status Codes
Complete reference for every HTTP status code — 1xx through 5xx. Search by number or keyword to find the meaning, use case, and common causes.
Informational
Request received, continuing process.
The server has received the request headers and the client should proceed to send the request body. Used with Expect: 100-continue header.
The server agrees to switch protocols. Common for upgrading an HTTP/1.1 connection to WebSocket.
WebDAV; server is processing but no response is available yet. Prevents the client from timing out.
Allows the browser to start preloading resources while the server prepares a full response. Improves page load speed significantly.
Success
The request was successfully received, understood, and accepted.
The request has succeeded. The meaning of success depends on the HTTP method: GET returns resource, POST returns result of action.
The request has been fulfilled and a new resource has been created. Typically used with POST or PUT. The new resource URL is in the Location header.
The request has been accepted for processing but hasn't been completed. Used for asynchronous operations — processing may happen later.
The returned metadata is from a local or third-party copy, not the origin server. Rare in practice.
The server has successfully fulfilled the request but there is no content to return. Common for DELETE operations or updates that don't return data.
Tells the client to reset the document that sent this request. For example, clear a form after submission.
Used for range requests. The server is delivering only part of the resource (video streaming, download resuming).
WebDAV. The response body contains multiple separate response codes, each applying to a different sub-request.
WebDAV. Used to avoid enumerating the internal members of multiple bindings to the same collection repeatedly.
The server has fulfilled a GET request and the response is a representation of the result of one or more instance-manipulations applied to the current instance.
Redirection
Further action needed to complete the request.
The request has more than one possible response. The user or user agent should choose one. No standard way of choosing automatically.
The URL of the requested resource has been changed permanently. The new URL is in the response. Browsers cache this redirect. Important for SEO — passes link equity.
The resource is temporarily at a different URI. Clients should continue using the original URL. Unlike 301, this is not cached permanently. Does NOT pass SEO equity.
Used to redirect after a POST/PUT/DELETE — tells the client to GET a different resource (typically a confirmation page). Prevents form resubmission.
Used with conditional requests (If-Modified-Since, If-None-Match). Tells the client its cached copy is current — saves bandwidth.
Like 302 but guarantees the method and body won't change. A POST to a 307 URL will POST to the new URL, not GET.
Like 301 but preserves the HTTP method. A POST to a 308 URL will POST to the new location permanently. Useful for API versioning.
Client Errors
The request contains bad syntax or cannot be fulfilled.
The server cannot or will not process the request due to a client error — malformed syntax, invalid request message framing, or deceptive request routing.
The client must authenticate itself to get the requested response. The response must include a WWW-Authenticate header. Different from 403 — here the client CAN get access by authenticating.
Originally intended for digital payment systems. Not widely used in standard HTTP. Some APIs use it for quota exceeded or subscription required.
The client does not have access rights to the content. Unlike 401, the client's identity is known to the server — they're just not allowed. No authentication will help.
The most famous status code. The server cannot find the requested resource. The URL is not recognised. Links that lead to a 404 are called broken links.
The request method is known but not supported by the target resource. E.g., using DELETE on a read-only resource. The response must include an Allow header.
The server cannot produce a response matching the list of acceptable values in the request's proactive content negotiation headers (Accept, Accept-Language, etc.).
Similar to 401, but the client must first authenticate with a proxy. The proxy must return a Proxy-Authenticate header.
The server timed out waiting for the request. Some servers send this on an idle connection without prior request. Client may resend the request.
The request conflicts with the current state of the server. Common in REST APIs when trying to create a duplicate resource or update with stale data (use with ETags).
The requested content has been permanently deleted from server with no forwarding address. Unlike 404, a 410 tells clients and search engines this is intentional and permanent.
The server rejected the request because the Content-Length header field is not defined and the server requires it.
The client has indicated preconditions in its headers which the server does not meet. Used with conditional requests (If-Match, If-Unmodified-Since).
The request entity is larger than limits defined by server. The server may close the connection or return a Retry-After header.
The URI requested by the client is longer than the server is willing to interpret. Rare — usually caused by a POST converted to a GET with a long query string.
The media format of the requested data is not supported by the server. The server is rejecting the request. Common API error — wrong Content-Type header.
The range specified by the Range header field in the request can't be fulfilled. Possibly out of bounds for the target URI's data.
The expectation indicated by the Expect request header field cannot be met by the server.
An April Fools' RFC 2324 joke from 1998 — any attempt to brew coffee with a teapot should result in this error code. Widely implemented as an Easter egg. Never intended for real use.
The request was directed at a server that is not able to produce a response. This can be sent by a server that is not configured to produce responses for the combination of scheme and authority.
The request was well-formed but was unable to be followed due to semantic errors. Common in REST APIs — e.g., validation failed (missing required field, wrong type).
WebDAV. The resource being accessed is locked.
WebDAV. The request failed because it depended on another request and that request failed.
Indicates the server is unwilling to risk processing a request that might be replayed — used in early data (0-RTT) in TLS 1.3.
The server refuses to perform the request using the current protocol but might do so after the client upgrades. The server sends an Upgrade header indicating the required protocol.
The origin server requires the request to be conditional, to prevent the 'lost update' problem — where a client GETs a resource, modifies it, then PUTs it back while a third party has changed it.
The user has sent too many requests in a given amount of time. The response should include a Retry-After header. This is the standard rate-limiting status code.
The server is unwilling to process the request because its header fields are too large. Common cause: oversized cookie.
The user requested a resource that cannot legally be provided. Named after Fahrenheit 451. Used for government censorship, DMCA takedowns, etc.
Server Errors
The server failed to fulfil a valid request.
The server has encountered a situation it doesn't know how to handle. A catch-all for server-side errors. Check server logs for the actual cause.
The request method is not supported by the server and cannot be handled. Only GET and HEAD are required to never return this code.
The server, acting as a gateway or proxy, received an invalid response from an upstream server. Common when a load balancer gets a bad response from a backend.
The server is not ready to handle the request — down for maintenance or overloaded. Should include a Retry-After header. Search engines will not de-index during brief 503s.
The server, acting as a gateway, did not receive a timely response from an upstream server. Similar to 408 but from a proxy/gateway perspective.
The HTTP version used in the request is not supported by the server.
The server has an internal configuration error: the chosen variant resource is configured to engage in transparent content negotiation itself.
WebDAV. The method could not be performed because the server cannot store the representation needed to successfully complete the request.
WebDAV. The server detected an infinite loop while processing the request.
Further extensions to the request are required for the server to fulfil it.
The client needs to authenticate to gain network access. Used by captive portals (hotel Wi-Fi login pages).
How to use it
- 1Type a code number (e.g. 404) or keyword (e.g. 'redirect') in the search box.
- 2Filter by category using the 1xx–5xx buttons to browse a specific class.
- 3Click any code card to expand its full explanation.
Common use cases
- Quickly look up what a specific HTTP error code means while debugging an API.
- Choose the correct status code to return from a REST API endpoint.
- Understand 3xx redirect codes and their SEO implications.
- Learn the difference between 401 Unauthorized and 403 Forbidden.
- Reference 5xx server error codes when diagnosing infrastructure issues.
Frequently asked questions
- What is HTTP status code 403 Forbidden?
- 403 Forbidden means the server understood the request and identified the client, but refuses to allow access to the resource. Unlike 401, authenticating or re-authenticating will not help — the client simply lacks permission. Common causes: insufficient file/folder permissions, an IP block, or an API key without the required scope.
- What is the difference between 301 and 302?
- 301 is a permanent redirect — browsers and search engines cache it and transfer SEO equity to the new URL. 302 is temporary — search engines keep indexing the original URL. Use 301 when you've permanently moved a page.
- What is the difference between 401 and 403?
- 401 Unauthorized means the client needs to authenticate — they might get access if they log in. 403 Forbidden means the server knows who you are but you're not allowed — authenticating won't help.
- When should I use 422 vs 400?
- Use 400 Bad Request for malformed syntax (invalid JSON, missing headers). Use 422 Unprocessable Content for valid syntax with semantic errors — e.g., a well-formed JSON body that fails business validation.
- What does 429 Too Many Requests mean?
- The client has exceeded a rate limit. The server response should include a Retry-After header telling the client when to try again. This is the standard code for rate limiting in APIs.
- Is 418 a real HTTP status code?
- It's real in the sense that it's defined in RFC 2324 as an April Fools' joke — 'I'm a teapot'. It was never intended for production use but is widely implemented as an Easter egg. It won't cause issues if returned, but you shouldn't use it in real APIs.