HTTP Status Code Reference — Look Up HTTP Codes Online
HTTP Status Code Reference explains every HTTP response status code: its standard phrase, which category it belongs to (1xx Informational, 2xx Success, 3xx Redirection, 4xx Client Error, 5xx Server Error), and a plain-English description of when and why it is returned. Paste a bare code (404), a full HTTP response line (HTTP/1.1 404 Not Found), or leave the input empty to see all codes grouped by category.
HTTP Status Code Categories
1xx Informational: the server has received the request headers and the client should proceed. Used primarily for connection upgrades (101 Switching Protocols for WebSockets) and early hints (103 for resource preloading). Rarely seen in typical REST API work.
2xx Success: the request was received, understood, and accepted. 200 OK is the standard success response. 201 Created is returned when a resource is newly created (POST to a collection). 204 No Content is used when the operation succeeds but there is nothing to return in the body (DELETE, some PATCHes). 206 Partial Content is used for ranged requests (resumable downloads).
3xx Redirection: the client must take further action to complete the request. 301 Moved Permanently and 308 Permanent Redirect are for permanent URL changes (301 may change method to GET; 308 preserves it). 302 Found and 307 Temporary Redirect are for temporary redirects. 304 Not Modified tells the client to use its cached version.
4xx Client Error: the request contains bad syntax or cannot be fulfilled by the server. These are the client's fault. 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 405 Method Not Allowed, 409 Conflict, 422 Unprocessable Entity, 429 Too Many Requests.
5xx Server Error: the server failed to fulfil an apparently valid request. These are the server's fault. 500 Internal Server Error (catch-all), 502 Bad Gateway (upstream failure), 503 Service Unavailable (overload/maintenance), 504 Gateway Timeout (upstream timeout).
API Design Guidance
Choosing the right status code makes your API self-documenting and easier to debug. Return 201 (not 200) when creating resources so clients know a new resource was created and can find its URL in the Location header. Return 204 (not 200 with an empty body) for successful deletes. Return 409 Conflict for duplicate-key violations rather than 500, so clients know it is a data conflict they can resolve.
For validation errors, return 422 with a body that lists each invalid field and its error message. This allows clients to display field-level error messages without parsing the error text. Structure the body consistently — for example: {"errors": [{"field": "email", "message": "Invalid format"}]}.
Never return 200 with an error body. Some legacy APIs return 200 with {"status": "error", "message": "..."}. This breaks every HTTP client and monitoring tool that uses the status code to determine success. Always use 4xx or 5xx for errors.
Common Use Cases
- Looking up the meaning of an unfamiliar HTTP status code in logs or API responses
- Understanding the difference between 301 and 308, or 401 and 403
- Debugging REST API errors by identifying the correct status code to return
- Reviewing all 5xx codes when investigating a production incident
- Learning HTTP semantics for API design
Frequently Asked Questions
What is the difference between 401 Unauthorized and 403 Forbidden?
401 means authentication is required and has not been provided (or the credentials are invalid). The client should re-authenticate. 403 means the server knows who you are but will not allow the action — the identity is authenticated but lacks permission. A 403 should not prompt re-authentication.
What is the difference between 301 and 302 redirects?
301 is a permanent redirect — the browser and search engines update their stored URL to the new location. 302 is temporary — the original URL should be used for future requests. For SEO, use 301 when permanently moving a page. In practice, both 301 and 302 typically change a POST to GET on redirect; use 307/308 to preserve the HTTP method.
When should an API return 422 vs 400?
400 Bad Request covers syntactically malformed requests (unparseable JSON, missing Content-Type). 422 Unprocessable Entity is used when the request is syntactically valid but fails semantic validation — for example, a JSON body with the correct structure but invalid field values. Many REST APIs use 422 for all input validation errors.
What causes a 502 Bad Gateway?
A 502 is returned by a reverse proxy (nginx, load balancer, API gateway) when the upstream server (your application) returned an invalid or no response. Common causes: the app crashed, the app is restarting, the app is overloaded and closing connections, or there is a network partition between the proxy and the app.
What is HTTP 429 Too Many Requests?
429 indicates that the client has exceeded a rate limit. The server may include a Retry-After header specifying when the client can make another request. Always handle 429 in API clients with exponential back-off and jitter.
Privacy & Security
This tool runs entirely in your browser using client-side JavaScript. No data is sent to a server — your input never leaves your machine. SmartDevBox has no account system, no usage tracking, and no paid tier. See the Privacy & Security page for full details.
Related Tools
- URL ParserParse any URL into its protocol, host, path, query parameters, and hash fragment instantly. Free, no sign-up, 100% client-side.
- JWT DecoderDecode JWT tokens and inspect header, payload, and signature instantly. Free, no sign-up. Works without the signing secret. 100% client-side.
- Cron Job ParserParse and explain cron expressions in plain English with next scheduled run times. Free, no sign-up, 100% client-side.