HTTP Status Code Reference
Free HTTP status code reference covering all 1xx–5xx codes with descriptions and developer tips. Search and filter instantly in your browser, no account required.
54 codes
Continue
The server has received the request headers and the client should proceed to send the request body.
Tip: Rarely seen in practice. Used for large uploads where the client checks if the server will accept before sending the full body.
Switching Protocols
The server agrees to switch protocols as requested by the client in the Upgrade header.
Tip: Commonly seen when upgrading from HTTP to WebSocket connections.
Processing
The server has received and is processing the request, but no response is available yet.
Tip: Used by WebDAV to prevent client timeouts on long operations.
Early Hints
Used to return some response headers before the final HTTP message.
Tip: Lets browsers preload resources (CSS, fonts) while the server finishes generating the full response.
OK
The request succeeded. The meaning depends on the HTTP method used.
Tip: The most common success response. GET returns the resource, POST returns the result of an action.
Created
The request succeeded and a new resource was created as a result.
Tip: Return this from POST endpoints that create resources. Include a Location header pointing to the new resource.
Accepted
The request has been received but not yet acted upon.
Tip: Use for async operations — the work will happen later. Consider returning a job ID so the client can poll for status.
No Content
The server successfully processed the request and is not returning any content.
Tip: Ideal for DELETE requests and updates where no response body is needed. Do not send a body with 204.
Partial Content
The server is delivering only part of the resource due to a Range header in the request.
Tip: Essential for video streaming and resumable file downloads. Check for Accept-Ranges: bytes support.
Multi-Status
Conveys information about multiple resources, used in WebDAV.
Tip: The response body contains an XML document describing the status of multiple sub-requests.
Already Reported
Used inside a DAV response to avoid enumerating internal members of multiple bindings to the same collection.
Tip: WebDAV-specific. Prevents infinite loops when the same resource appears in multiple collections.
IM Used
The server has fulfilled a GET request and the response is a representation of the result of one or more instance-manipulations.
Tip: Used with HTTP delta encoding (RFC 3229). Rare in typical web applications.
Multiple Choices
The request has more than one possible response. The user or user agent should choose one.
Tip: Rarely used. Modern APIs prefer to pick the best representation automatically using content negotiation.
Moved Permanently
The URL of the requested resource has been changed permanently. The new URL is given in the response.
Tip: Use for permanent URL changes (SEO-friendly). Browsers and crawlers will update their bookmarks/indexes.
Found
The URI of the requested resource has been changed temporarily.
Tip: Use for temporary redirects. Be careful — some clients change POST to GET on redirect. Consider 307 instead.
See Other
The response to the request can be found under another URI using the GET method.
Tip: Use after a POST to redirect to a confirmation page. This is the Post/Redirect/Get (PRG) pattern.
Not Modified
Used for caching purposes. Tells the client the response has not been modified, so the cached version can be used.
Tip: Requires the client to send If-None-Match or If-Modified-Since headers. Saves bandwidth on repeated requests.
Temporary Redirect
The server is temporarily redirecting the client to a different URI using the same method as the original request.
Tip: Unlike 302, the client must use the same HTTP method for the redirect. Use this instead of 302 when the method matters.
Permanent Redirect
The resource is now permanently located at another URI using the same HTTP method as the original.
Tip: The permanent equivalent of 307. Use instead of 301 when the method must not change (e.g., keeping POST as POST).
Bad Request
The server cannot or will not process the request due to something perceived to be a client error.
Tip: Include an error message explaining what was wrong. Common causes: malformed JSON, missing required fields, invalid values.
Unauthorized
The client must authenticate itself to get the requested response.
Tip: Despite the name, this means "unauthenticated". Include a WWW-Authenticate header. Use 403 when identity is known but access is denied.
Payment Required
Reserved for future use, originally intended for digital payment systems.
Tip: Some APIs use this informally to indicate a paid feature limit has been reached. Not standardized — document clearly.
Forbidden
The client does not have access rights to the content; unlike 401, the identity is known.
Tip: The server knows who you are but you do not have permission. Do not reveal why access is denied to prevent information leakage.
Not Found
The server cannot find the requested resource. The URL is not recognized.
Tip: Also used to hide the existence of a resource from unauthorized users (prefer 403 when you want to be explicit).
Method Not Allowed
The request method is known by the server but is not supported by the target resource.
Tip: Always include an Allow header listing the supported methods (e.g., Allow: GET, POST).
Not Acceptable
The server cannot produce a response matching the list of acceptable values in the request's proactive content negotiation headers.
Tip: Returned when the server cannot match the Accept, Accept-Encoding, or Accept-Language headers.
Request Timeout
The server would like to shut down this unused connection.
Tip: The server timed out waiting for the client to send the full request. May appear during slow uploads.
Conflict
The request conflicts with the current state of the server.
Tip: Use when a duplicate resource is being created or an edit conflicts with concurrent changes. Return the conflicting state.
Gone
The content has been permanently deleted from the server, with no forwarding address.
Tip: Unlike 404, 410 signals intentional permanent removal. Useful for content that has been deliberately taken down.
Length Required
The server refuses to accept the request without a defined Content-Length header.
Tip: Add a Content-Length header to your POST/PUT requests when this occurs.
Precondition Failed
The client has indicated preconditions in its headers which the server does not meet.
Tip: Returned when If-Match or If-Unmodified-Since conditions fail. Used for optimistic concurrency control.
Payload Too Large
The request entity is larger than limits defined by the server.
Tip: Check server upload limits. Common with file upload APIs. The server may close the connection or return Retry-After.
URI Too Long
The URI requested by the client is longer than the server is willing to interpret.
Tip: Move large query parameters to the request body using POST instead of a long GET query string.
Unsupported Media Type
The media format of the requested data is not supported by the server.
Tip: Check the Content-Type header matches what the endpoint expects (e.g., application/json vs. multipart/form-data).
I'm a Teapot
The server refuses to brew coffee because it is, permanently, a teapot.
Tip: An April Fools' joke from RFC 2324. Some servers implement it as an Easter egg or to reject clearly invalid requests.
Unprocessable Entity
The request was well-formed but was unable to be followed due to semantic errors.
Tip: Use when the JSON is valid but the data fails business logic validation. Return a list of validation errors in the response body.
Locked
The resource that is being accessed is locked.
Tip: WebDAV-specific. The resource is currently locked by another user or process.
Failed Dependency
The request failed because it depended on another request and that request failed.
Tip: WebDAV-specific. Part of a batch operation where a prerequisite step failed.
Too Early
The server is unwilling to risk processing a request that might be replayed.
Tip: Used with TLS 1.3 early data (0-RTT). Prevents replay attacks on non-idempotent requests.
Upgrade Required
The server refuses to perform the request using the current protocol.
Tip: The server indicates the client should switch protocols (specified in the Upgrade header).
Precondition Required
The origin server requires the request to be conditional.
Tip: Use to prevent "lost update" problems. Forces clients to send If-Match to confirm they have the current state.
Too Many Requests
The user has sent too many requests in a given amount of time (rate limiting).
Tip: Include a Retry-After header. Implement exponential backoff when hitting this. A common signal to throttle your API client.
Request Header Fields Too Large
The server is unwilling to process the request because its header fields are too large.
Tip: Often caused by very large cookies. Clear cookies or reduce the number of request headers.
Unavailable For Legal Reasons
The user requested a resource that cannot legally be provided, such as a web page censored by a government.
Tip: Named after the Ray Bradbury novel Fahrenheit 451. Use instead of 403 to clearly indicate legal, not technical, restrictions.
Internal Server Error
The server has encountered a situation it does not know how to handle.
Tip: Log the full error server-side. Return a generic message to the client — never expose stack traces in production responses.
Not Implemented
The request method is not supported by the server and cannot be handled.
Tip: The server does not recognize the request method. Unlike 405, this means the server never supports it (not just for this resource).
Bad Gateway
The server, while acting as a gateway or proxy, received an invalid response from the upstream server.
Tip: Usually a problem between your reverse proxy (nginx, Cloudflare) and your application server. Check upstream service health.
Service Unavailable
The server is not ready to handle the request. Common causes are a server down for maintenance or overloaded.
Tip: Include a Retry-After header when possible. Common during deployments or when circuit breakers trip.
Gateway Timeout
The server, while acting as a gateway, did not get a response in time from the upstream server.
Tip: The upstream server is taking too long. Check for slow database queries, external API timeouts, or overloaded services.
HTTP Version Not Supported
The HTTP version used in the request is not supported by the server.
Tip: Rare in practice. Ensure client and server agree on HTTP/1.1 or HTTP/2.
Insufficient Storage
The server is unable to store the representation needed to complete the request.
Tip: WebDAV-specific but useful beyond it. Check server disk space when this appears.
Loop Detected
The server detected an infinite loop while processing the request.
Tip: WebDAV-specific. A resource is referencing itself in a way that creates an infinite loop.
Not Extended
Further extensions to the request are required for the server to fulfill it.
Tip: The server requires additional HTTP extensions that the client did not include in the request.
Network Authentication Required
The client needs to authenticate to gain network access.
Tip: Typically returned by captive portals (hotel Wi-Fi, etc.) when browser authentication is needed before accessing the internet.