HTTP Status Codes

About HTTP status codes

A searchable reference of 63 HTTP status codes across the 1xx to 5xx classes. Each entry gives the official name, what it means, when to return it and the RFC section that defines it. Filter by class, search by number or keyword, and hide the single unofficial code if you want only standardized ones.

How to use it

1. Type a code, name or phrase such as 429, rate limiting or redirect into Search. Matching covers the code, the name, the meaning and the usage guidance.
2. Use the Category buttons, All, 1xx, 2xx, 3xx, 4xx and 5xx, to narrow the table. A one-line summary of the class appears below them.
3. Turn off Include unofficial and vendor-specific codes to hide entries such as 499.
4. Read Meaning and When to use it for each row, and the Spec column for the RFC section.
5. Press the copy icon on a row to copy the code with its name, for example 404 Not Found.

When to use it

• Choosing between 401 and 403 when designing the authentication errors of an API.
• Deciding whether a moved page needs a 301, 302, 307 or 308 redirect.
• Decoding an unfamiliar code that showed up in a proxy or load balancer log, such as 499.
• Checking which responses a client can sensibly retry, for example 429 and 503 when Retry-After is present.

Questions about HTTP status codes

What is the difference between 401 and 403?

401 means the request lacks valid authentication credentials, and the client can try again with them. 403 means the server knows who is asking and still refuses. The name Unauthorized for 401 is a historical quirk.

Which redirect codes keep the request method?

307 and 308 preserve the method and body. 301 and 302 let clients turn a POST into a GET, which is why 308 is the modern permanent choice for APIs.

What is 499?

It is an nginx-specific code recorded when a client closes the connection before the server responds. It appears in no RFC, so the table marks it Unofficial.

Why is 418 in the list?

It comes from the April Fools' RFC 2324 and is included because some services return it on purpose. It is not intended for real error handling.

Which code suits a validation failure?

400 is the general choice for a malformed request, while 422 fits a well-formed request whose content fails semantic checks. Pick one convention and document it for your API's users.

Related tools

• JSON Schema generatorGenerate a draft 2020-12 JSON Schema from a JSON sample, with format detection and optional enums.
• HTML minifierMinify your HTML by removing all the unnecessary characters.
• CSS minifierMinify your CSS by removing all the unnecessary characters.
• JS minifierMinify your JS by removing all the unnecessary characters.
• JSON validator & beautifierValidate JSON content and make it looks good.
• SQL formatter/beautifierFormat & beautify your SQL code with ease.