HTTP Status Codes
Every HTTP status code explained in plain English — from 100 Continue to 504 Gateway Timeout. Includes practical debugging tips for when you encounter each one.
The server has received the request headers and the client should proceed to send the request body.
When you see this: Rarely seen in practice. Used in large file uploads where the client sends Expect: 100-continue first.
The server agrees to switch protocols as requested by the client.
When you see this: Seen when upgrading from HTTP to WebSocket. The connection stays open after this response.
The server has received and is processing the request, but no response is available yet.
When you see this: Used by WebDAV servers for long-running operations to prevent client timeouts.
Used to return some response headers before final HTTP message while the server is still preparing a response.
When you see this: Allows browsers to start preloading resources (CSS, fonts) before the actual page response arrives.
The request succeeded. The response body contains the requested resource.
When you see this: The standard success response for GET and POST requests. Most API calls return this on success.
The request succeeded and a new resource was created as a result.
When you see this: Returned after a successful POST that creates a resource. The Location header often points to the new resource URL.
The request has been received but not yet acted upon. Processing is asynchronous.
When you see this: Returned by background jobs or queues. The client should poll or wait for a webhook to know the outcome.
The request succeeded but there is no content to send in the response body.
When you see this: Common for DELETE requests and PUT/PATCH operations that do not return the updated resource.
The server is delivering only part of the resource because of a Range header in the request.
When you see this: Used for video streaming and resumable downloads. The client requested a specific byte range.
The requested URL has been permanently moved to a new URL provided in the Location header.
When you see this: Use for permanent URL changes. Search engines transfer link equity to the new URL and update their index.
The requested URL is temporarily located at the URL given in the Location header.
When you see this: Use for temporary redirects. Search engines keep the original URL indexed. Often misused when 301 is intended.
The response to the request can be found at another URI using a GET method.
When you see this: Returned after a POST to redirect the client to a confirmation page, preventing form resubmission on refresh.
The resource has not been modified since the version specified in the request headers.
When you see this: The browser's cached version is still valid. No body is sent — the browser uses its local copy, saving bandwidth.
The request should be repeated with the new URI, but future requests should still use the original URI.
When you see this: Like 302 but guarantees the HTTP method and body are preserved. Use for temporary POST redirects.
The resource has been permanently moved. The HTTP method must not change when reissuing the request.
When you see this: Like 301 but method-preserving. Use when permanently moving a POST endpoint.
The server cannot process the request due to malformed syntax, invalid parameters, or missing required fields.
When you see this: Your request body, query parameters, or headers contain an error. Check your JSON syntax and required fields.
Authentication is required and has failed or has not yet been provided.
When you see this: Your request is missing a valid auth token, or the token has expired. Log in again or refresh your access token.
The server understood the request but refuses to authorize it.
When you see this: You are authenticated but lack the required permissions. Contact an admin to adjust your access level.
The server cannot find the requested resource. The URL is either wrong or the resource has been removed.
When you see this: The page or API endpoint does not exist. Check for typos, trailing slashes, or whether the resource was deleted.
The HTTP method used in the request is not supported for the target resource.
When you see this: You sent a POST to an endpoint that only accepts GET. The Allow response header lists valid methods.
The server closed the connection because the client took too long to complete the request.
When you see this: Your connection was too slow or the request was abandoned mid-send. Retry with a better connection.
The request conflicts with the current state of the resource.
When you see this: Common in concurrent edits — you are trying to create a resource that already exists, or update a stale version.
The request body is larger than limits defined by the server.
When you see this: Your file upload or request body exceeds the server's size limit. Compress the data or split it into smaller requests.
The server refuses to accept the request because the media format is not supported.
When you see this: You sent XML when the API expects JSON. Set the correct Content-Type header (e.g. application/json).
The server understands the content type but cannot process the instructions contained in the request.
When you see this: Common in REST and GraphQL APIs when validation fails — a required field is missing or a value is out of range.
The client has sent too many requests in a given amount of time (rate limiting).
When you see this: You have hit the API rate limit. Check the Retry-After header and implement exponential backoff in your client.
The server is denying access to the resource as a consequence of a legal demand.
When you see this: The content has been blocked by a government order or legal takedown notice in your region.
The server encountered an unexpected condition that prevented it from fulfilling the request.
When you see this: Something went wrong on the server side. Check server logs. This is a bug to investigate, not a client error.
The server does not support the functionality required to fulfill the request.
When you see this: The HTTP method used is not supported by the server at all. Rarely seen outside HTTP/1.1 method negotiations.
The server, acting as a gateway or proxy, received an invalid response from an upstream server.
When you see this: Your reverse proxy (nginx, Cloudflare) cannot reach the backend. The backend service may have crashed or restarted.
The server is not ready to handle the request — typically due to overload or temporary maintenance.
When you see this: The service is down but should recover. Usually returns a Retry-After header. Set up health checks and alerting.
The server, acting as a gateway or proxy, did not receive a timely response from an upstream server.
When you see this: The backend took too long to respond. The request may still be processing — check your backend performance.
HTTP Status Code FAQ
Common questions about HTTP response codes and how to interpret them.
What is an HTTP status code?+
An HTTP status code is a three-digit number returned by a web server in response to a client's request. It indicates whether the request succeeded, failed, or requires further action. Status codes are grouped into five classes: 1xx (informational), 2xx (success), 3xx (redirection), 4xx (client error), and 5xx (server error).
What is the difference between 301 and 302 redirects?+
A 301 (Moved Permanently) redirect tells browsers and search engines that the resource has moved forever. The new URL should be indexed and link equity transferred. A 302 (Found) redirect is temporary — search engines keep the original URL indexed. Use 301 for permanent URL changes and 302 for temporary redirects like A/B tests.
What causes a 403 error vs a 401 error?+
A 401 (Unauthorized) error means authentication is required but missing or invalid — the client needs to log in. A 403 (Forbidden) error means the server knows who the client is but refuses access — the authenticated user lacks the required permissions.
What does HTTP 429 mean?+
429 Too Many Requests means the client has sent too many requests in a given time window and has been rate-limited. The response usually includes a Retry-After header indicating when the client can try again.
What is the difference between 502 and 503?+
502 Bad Gateway means a gateway or proxy received an invalid response from an upstream server — typically a backend crash or misconfiguration. 503 Service Unavailable means the server is temporarily unable to handle the request due to overload or maintenance, and the service should recover on its own.