HTTP Status Codes Reference

Every HTTP response starts with a status code that tells the client what happened. They are grouped by their first digit: 1xx informational, 2xx success, 3xx redirection, 4xx client error and 5xx server error.

Type a code to read its meaning, or a word such as redirect or timeout to find related codes. Leave it empty to see the full list.

Key features

• Lookup by code number
• Search by keyword in the name, description or category
• Covers 1xx to 5xx including common WebDAV codes
• Instant results

How to use

1. Type a code such as 404, or a word such as redirect.
2. Read the meaning.
3. Clear the box to browse the whole list.

Use cases

• Understanding an error from an API or server log
• Choosing the right status code for your own API
• Telling a 301 from a 302, or a 401 from a 403

In depth

HTTP status codes are defined in RFC 9110, which obsoleted the earlier RFC 7231, and are maintained in the IANA registry. The first digit gives the class, and a client that does not recognise a specific code must treat it like the x00 code of its class. So an unknown 499 is handled like 400. Semantics matter more than the number: 200 means the request succeeded, 201 means a resource was created, 204 means success with no body, and 304 means the cached copy is still valid. Choosing precisely helps caches, browsers, crawlers and API clients behave correctly.

Redirect codes illustrate the subtlety. 301 and 302 allow clients to change a POST into a GET when following the redirect, which is why 307 and 308 were defined to preserve the original method; 308 is the permanent one and 307 the temporary one. Among errors, 400 reports a malformed request, 422 a well formed request with invalid content, 429 too many requests, 502 a bad response from an upstream server, 503 temporary unavailability and 504 an upstream timeout. A 5xx suggests the fault lies with the server, so clients may retry, while most 4xx errors need the request to change first.

Tips

• When designing an API, return 401 only when authentication is missing or invalid, and 403 when the user is known but not permitted. Mixing them up confuses clients and makes debugging harder.
• Use 308 or 307 instead of 301 or 302 when redirecting POST or PUT requests, because the older codes let some clients switch to GET and silently drop the request body.
• Do not return 200 with an error message in the body. Monitoring tools, caches and client libraries rely on the status code, so a failure hidden behind 200 goes unnoticed.

Related tools

• Card Number Validator (Luhn) Check a card number with the Luhn algorithm and detect its network.
• Chmod Calculator Work out Unix file permissions in octal and symbolic form.
• CIDR and Subnet Calculator Calculate network, broadcast and host range from a CIDR block.
• Cron Expression Explainer Explain a cron schedule and see its next run times.
• Regex Tester Test regular expressions and see every match and capture group.
• Unix Timestamp Converter Convert Unix timestamps to dates and dates to timestamps.