HTTP Status Code Reference
Searchable reference of HTTP status codes.
Continue
The server received the request headers and the client should proceed to send the body.
Switching Protocols
The server is switching protocols as requested by the client.
Processing
The server has received and is processing the request, but no response is available yet.
Early Hints
Used to return some response headers before the final HTTP message.
OK
The request succeeded. The meaning depends on the HTTP method used.
Created
The request succeeded and a new resource was created.
Accepted
The request has been accepted for processing, but processing is not complete.
No Content
The request succeeded but returns no body content.
Partial Content
The server is delivering only part of the resource due to a range header.
Moved Permanently
The resource has been permanently moved to a new URL.
Found
The resource resides temporarily under a different URL.
See Other
The response can be found under another URL using a GET request.
Not Modified
The cached version of the resource is still valid; no need to retransmit.
Temporary Redirect
The request should be repeated with another URL, keeping the method.
Permanent Redirect
The resource is permanently at another URL, keeping the method.
Bad Request
The server cannot process the request due to a client error (e.g. malformed syntax).
Unauthorized
Authentication is required and has failed or not been provided.
Forbidden
The client is authenticated but does not have permission for the resource.
Not Found
The requested resource could not be found on the server.
Method Not Allowed
The request method is not supported for the target resource.
Request Timeout
The server timed out waiting for the request.
Conflict
The request conflicts with the current state of the server.
Gone
The resource is no longer available and will not be available again.
Unsupported Media Type
The media format of the request data is not supported.
Unprocessable Entity
The request was well-formed but has semantic (validation) errors.
Too Many Requests
The user has sent too many requests in a given amount of time (rate limiting).
Internal Server Error
A generic error occurred on the server.
Not Implemented
The server does not support the functionality required to fulfill the request.
Bad Gateway
The server, acting as a gateway, received an invalid response from an upstream server.
Service Unavailable
The server is not ready to handle the request (overloaded or down for maintenance).
Gateway Timeout
The upstream server failed to send a response in time.
HTTP Version Not Supported
The HTTP version used in the request is not supported by the server.
About HTTP Status Code Reference
The HTTP Status Code Reference is a searchable catalog of every status code you will meet while testing APIs — what each one means, and the situations where it is the right (or suspiciously wrong) response. Filter by class or search by number or keyword to settle "is 422 appropriate here?" debates in seconds.
For testers, status codes are assertions: the difference between 401 and 403, or 301 and 302, is exactly the kind of contract detail worth a test case. Having the definitions one search away keeps bug reports precise.
How to use
- Type a code or keyword into "Search" — for example 429 or "timeout".
- Or narrow by "Class" — 2xx success, 3xx redirects, 4xx client errors, 5xx server errors.
- Read the description and use the exact semantics in your test assertion or bug report.
Frequently asked questions
What is the difference between 401 and 403?
401 Unauthorized means "not authenticated" — no or invalid credentials; the request may succeed after logging in. 403 Forbidden means "authenticated but not allowed" — better credentials will not help. APIs that mix them up create both confusion and security-test findings.
When should an API return 422 instead of 400?
400 Bad Request suits malformed syntax (broken JSON); 422 Unprocessable Content suits well-formed requests that fail validation (email field with no @). Many APIs use 400 for both — what matters for testing is that the contract is consistent.
Why treat 5xx differently from 4xx in tests?
4xx codes blame the client and are often expected behavior to assert on; any 5xx blames the server and is almost always a defect. A load test that produces 429s is behaving; one that produces 500s has found a bug.