HTTP STATUS CODES
Complete reference + live URL tester
LIVE TESTER
REFERENCE
The client should continue sending the request body. The server has received the headers.
Used with Expect: 100-continue header to avoid sending large bodies unnecessarily.
The server agrees to switch protocols as requested by the client.
Sent in response to an Upgrade request (e.g., upgrading to WebSocket).
The server has received and is processing the request, but no response is available yet.
WebDAV — prevents client timeout when a long operation is in progress.
Return preliminary HTTP headers before final response to let the browser preload resources.
Performance optimization — send Link headers early so the browser starts fetching assets.
The request succeeded. The meaning depends on the HTTP method used.
Standard success response for GET, POST, PUT, PATCH, DELETE.
The request succeeded and a new resource was created as a result.
Return after POST or PUT that creates a new resource. Include Location header.
The request has been received but not yet acted upon. It is noncommittal.
Async processing — request is queued/scheduled but not complete yet.
The server successfully processed the request and is not returning any content.
DELETE, or PUT/PATCH when no body needed in response. Also CORS preflight.
The server is delivering only part of the resource due to a range request from the client.
Range requests (e.g., video streaming, resumable downloads). Requires Range header.
The response body contains multiple status codes for different sub-requests.
WebDAV bulk operations (PROPFIND, MULTI-STATUS).
The URL of the requested resource has been changed permanently. The new URL is in the Location header.
Permanent URL changes — HTTP to HTTPS redirect, domain changes. Browsers cache this.
The resource is temporarily located at a different URL. Future requests should use the original URL.
Temporary redirects. Note: many clients change POST to GET after following. Use 307 to preserve method.
Redirect the client to GET another resource. Used after POST to redirect to a results page.
Post/Redirect/Get pattern. Prevents double-submission on browser refresh.
The response has not been modified. Client can use its cached version.
Conditional GET requests using If-None-Match or If-Modified-Since headers.
Temporary redirect that preserves the original HTTP method and body.
Like 302, but guarantees method is preserved (POST → POST, not POST → GET).
Permanent redirect that preserves the HTTP method. Like 301 but method is not changed.
Permanent URL migration where you need POST/PUT to remain POST/PUT.
The server cannot process the request due to a client error (malformed syntax, invalid framing, etc.).
Invalid JSON body, missing required fields, malformed query params, validation errors.
The client must authenticate itself to get the requested response.
Missing or invalid authentication credentials. Include WWW-Authenticate header.
The client does not have access rights to the content. Unlike 401, the client's identity is known.
Authenticated but not authorized. User lacks permission for this action/resource.
The server cannot find the requested resource. The URL is not recognized.
Resource doesn't exist. Also used to hide 403 (not revealing protected resources exist).
The request method is known by the server but is not supported by the target resource.
POST to a read-only endpoint, DELETE on a non-deletable resource. Must include Allow header.
The server would like to shut down this unused connection.
Client took too long to send the request. Some servers send this on idle connections.
The request conflicts with the current state of the server.
Duplicate resource creation, optimistic concurrency conflict, version mismatch.
The content has been permanently deleted from the server, with no forwarding address.
Resource intentionally removed and won't return. Unlike 404, indicates permanent removal.
The request body is larger than limits defined by server.
File upload exceeds max size, request body too large. Include Retry-After if temporary.
The media format of the requested data is not supported by the server.
Wrong Content-Type header (e.g., sending XML to a JSON-only endpoint).
The server refuses to brew coffee because it is, permanently, a teapot.
April Fools RFC 2324. Sometimes used as an Easter egg or to reject bad requests playfully.
The server understands the content type and syntax but cannot process the contained instructions.
Validation errors — request is well-formed but semantically incorrect (e.g., invalid email format).
The user has sent too many requests in a given amount of time.
Rate limiting. Include Retry-After header with seconds or date to retry.
The user requested a resource that cannot legally be provided.
Content blocked by legal order (DMCA, court order, government censorship).
The server encountered an unexpected condition that prevented it from fulfilling the request.
Unhandled exception, bug, or unexpected server-side failure. Generic catch-all.
The request method is not supported by the server and cannot be handled.
Server doesn't support the HTTP method. Differs from 405 (which means the method exists but not for this route).
The server, while working as a gateway, received an invalid response from an upstream server.
Reverse proxy (Nginx/Caddy) can't reach the upstream app. App crashed or wrong port.
The server is not ready to handle the request. Common causes: maintenance or overload.
Server down for maintenance, overloaded, or starting up. Include Retry-After header.
The server, acting as a gateway, did not receive a timely response from an upstream server.
Upstream server took too long. Check app server timeout settings and slow queries.
The method could not be performed because the server cannot store the representation needed.
Disk full on server. WebDAV context.