HTTP Status Codes
Browse, filter, read troubleshooting guides, and use the decision tree to find the right status code.
HTTP STATUS · Success
207Multi-Status
Conveys information about multiple resources in situations where multiple status codes might be appropriate (WebDAV).
Live Mock API Endpoints
Need to test your app's error handling? Use the free https://httpstatus.in service to generate real HTTP responses.
100 — Informational
The server has received the request headers and the client should proceed to send the request body.
The requester has asked the server to switch protocols and the server has agreed to do so.
The server has received and is processing the request, but no response is available yet (WebDAV).
Used to return some response headers before final HTTP message, useful for preloading resources.
200 — Success
The request succeeded. The meaning depends on the HTTP method: GET returns the resource, POST returns the result.
The request succeeded, and a new resource was created. The Location header should point to the new resource.
The request has been received but not yet acted upon. Used for async processing (e.g. background jobs).
There is no content to send for this request, but the headers may be useful. Used for DELETE or PATCH with no body.
Tells the user-agent to reset the document that sent this request — useful after submitting a form.
This response is used when the Range header is sent from the client to request only part of a resource (e.g. video streaming).
Conveys information about multiple resources in situations where multiple status codes might be appropriate (WebDAV).
Used inside a DAV propstat response element to avoid enumerating bindings repeatedly (WebDAV).
The server has fulfilled a GET request, and the response is a representation of the result of one or more instance-manipulations.
300 — Redirection
The request has more than one possible response. The user agent or user should choose one.
The URL of the requested resource has been changed permanently. The new URL is given in the Location header.
The URI of the requested resource has been changed temporarily. The client should use the original URL in future requests.
The server sends this response to direct the client to get the resource at another URI with a GET request — typically after a POST.
The response has not been modified, so the client can continue to use the cached version. Used with If-None-Match and If-Modified-Since headers.
The resource is temporarily located at another URI. Unlike 302, the HTTP method must not change.
The resource is now permanently at another URI. Like 301, but the HTTP method must not change (POST stays POST).
400 — Client Error
The server cannot or will not process the request due to malformed syntax, invalid request message framing, or deceptive request routing.
Reserved for future use, but increasingly used by SaaS APIs to signal a rate limit or subscription requirement.
The client does not have access rights to the content. Unlike 401, the client's identity is known but they lack permission.
The server cannot find the requested resource. The URL is not recognized. May also be returned intentionally to hide existence of a resource.
The request method is known by the server but not supported by the target resource. The Allow header must be returned.
No content conforming to the criteria given by the user agent's Accept headers was found.
Authentication must be done by a proxy before the request is served.
The server timed out waiting for the request. The client may repeat the request.
The request conflicts with the current state of the server. Usually occurs with PUT requests and version control.
The requested content has been permanently deleted from the server and will not be reinstated. Preferred over 404 for deliberately removed content.
Server rejected the request because the Content-Length header is not defined and the server requires it.
The client has indicated preconditions in its headers which the server does not meet (e.g. If-Match, If-Unmodified-Since).
Request entity is larger than limits defined by the 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.
The media format of the requested data is not supported by the server.
The range specified by the Range header in the request can't be fulfilled. Possibly out of bounds for the resource.
The expectation indicated by the Expect request header can't be met by the server.
The server refuses to brew coffee because it is, permanently, a teapot. An April Fools' joke from RFC 2324 (1998) — now a real status code.
The request was directed at a server that is not able to produce a response (HTTP/2 connection reuse issue).
The request was well-formed but could not be processed due to semantic errors (e.g. validation failures).
The resource that is being accessed is locked (WebDAV). No modifications are allowed until the lock is released.
The request failed because it depended on another request that failed (WebDAV).
Indicates that the server is unwilling to risk processing a request that might be replayed (TLS 1.3 early data).
The server refuses to perform the request using the current protocol but will accept it using a different protocol.
The origin server requires the request to be conditional to prevent lost update problems.
The user has sent too many requests in a given amount of time (rate limiting). The response should include a Retry-After header.
The server is unwilling to process the request because its header fields are too large.
500 — Server Error
The server has encountered a situation it does not know how to handle. This is a generic catch-all error.
The request method is not supported by the server and cannot be handled. Only GET and HEAD may not produce 501.
The server, while acting as a gateway or proxy, received an invalid response from the upstream server.
The server is acting as a gateway and did not get a timely response from an upstream server.
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.
The server is unable to store the representation needed to complete the request (WebDAV).
The server detected an infinite loop while processing the request (WebDAV).
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, etc.).
HTTP Status Codes: A Developer's Reference
HTTP status codes are the three-digit responses a server sends to tell the client what happened to its request. Every web developer encounters them daily — in browser DevTools, API responses, server logs, and monitoring dashboards. Knowing what each code means and when to use it is fundamental to building and debugging web applications.
The five classes
2xx — Success
The request was received, understood, and accepted. 200 OK is the standard success response. 201 Created confirms a resource was created. 204 No Content is used for successful DELETEs.
3xx — Redirection
301 is permanent (passes SEO equity). 302 is temporary. 304 Not Modified tells the client its cached version is still valid — no body is sent, saving bandwidth.
4xx — Client Errors
400 bad syntax, 401 unauthenticated, 403 forbidden, 404 not found, 429 rate limited. These indicate the client sent a bad or unauthorized request.
5xx — Server Errors
500 internal error, 502 bad gateway, 503 service unavailable, 504 gateway timeout. These indicate the server failed despite a valid request.
SEO impact of redirects
Redirect chains and incorrect redirect types are among the most common technical SEO mistakes. A 301 passes ~99% of link equity to the destination URL. A 302does not reliably pass equity — Google may keep the original URL indexed. Redirect chains (A → B → C) dilute equity at each hop and slow page load. Always redirect directly to the final destination with a 301.
Pipeline
- cURL to Code — convert API requests that return these codes to runnable code.
- API Response Mockup — mock endpoints that return specific status codes for testing.
Frequently asked
- What are the five classes of HTTP status codes?
- 1xx Informational (request received, continuing), 2xx Success (request fulfilled), 3xx Redirection (further action needed), 4xx Client Error (bad request from the client), 5xx Server Error (server failed to fulfill a valid request).
- What is the difference between 301 and 302?
- A 301 Moved Permanently tells browsers and search engines the resource has moved forever — link equity (PageRank) transfers to the new URL. A 302 Found is temporary; search engines keep the original URL indexed and do not reliably pass link equity. Use 301 for permanent SEO-safe redirects.
- What is the difference between 401 and 403?
- 401 Unauthorized means the request lacks valid authentication credentials — the client should authenticate and retry. 403 Forbidden means the server understood the request but refuses to authorize it — authentication will not help.
- When should I use 422 instead of 400?
- 400 Bad Request is for malformed syntax (e.g. invalid JSON). 422 Unprocessable Entity is for syntactically valid requests that fail semantic validation (e.g. a well-formed JSON body where a required field has an invalid value). REST APIs commonly use 422 for validation errors.
- What causes a 504 Gateway Timeout?
- A 504 means an upstream server (e.g. a microservice, database, or external API) did not respond in time. The gateway or proxy received no timely response. Common causes: slow database queries, overloaded upstream services, or network partitions.