HTTP Status Code Finder

Find the right HTTP status code for your API. Answer questions about your scenario or search by code and keyword. Decision tree and search.

Finder

How to Use

1
Choose your mode
Use the Decision Tree to answer yes/no questions about your API scenario, or use Search to filter all 60+ HTTP status codes by code number, name, or keyword.
2
Answer the questions or search
The decision tree narrows down the correct code in 3-5 steps. Or try a common preset like 'API created resource' for instant results.
3
Get the recommended code
See the recommended status code with its description, use case, and a link to the full detail page with examples and RFC references.

About

HTTP status codes are three-digit numbers returned by web servers to indicate the outcome of a client's request. Defined in RFC 7231 (part of the HTTP/1.1 specification suite) and later refined in RFC 9110, these codes form the backbone of communication between web clients and servers.

The status code system traces its origins to HTTP/0.9 in 1991, which had no status codes at all. HTTP/1.0 (RFC 1945, 1996) introduced the three-digit code system with five categories. HTTP/1.1 (RFC 2616, 1999) expanded the list significantly, and the 2014 rewrite (RFC 7230-7235) reorganized the specification for clarity. The latest revision, RFC 9110 (2022), is the current authoritative reference.

Choosing the correct status code matters for several reasons. REST APIs rely on status codes for clients to handle responses programmatically. Search engines use 301 vs 302 to determine whether to transfer link equity. CDNs and proxies cache responses based on status codes. Monitoring tools alert on 5xx rates.

This tool helps you find the right HTTP status code in two ways. The Decision Tree guides you through yes/no questions about your API scenario and recommends the most appropriate code in 3 to 5 steps. The Search mode lets you filter all 60+ HTTP status codes by number, name, or keyword.

FAQ

What are the five categories of HTTP status codes?

HTTP status codes are grouped into five classes: 1xx (Informational) for provisional responses like 100 Continue; 2xx (Success) for fulfilled requests like 200 OK and 201 Created; 3xx (Redirection) for resources that have moved, like 301 and 302; 4xx (Client Error) for bad requests, authentication issues, and missing resources like 400, 401, 403, and 404; and 5xx (Server Error) for server-side failures like 500, 502, and 503.

What is the difference between 301 and 302 redirects?

301 Moved Permanently tells clients and search engines that the resource has moved forever -- browsers cache this and search engines transfer link equity to the new URL. 302 Found indicates a temporary redirect -- the original URL should still be used for future requests. Use 301 for domain migrations and URL restructuring; use 302 for maintenance pages, A/B tests, and login redirects.

What is the difference between 401 Unauthorized and 403 Forbidden?

401 Unauthorized means the client has not provided valid authentication credentials -- the user needs to log in or provide a valid API key. 403 Forbidden means the client is authenticated (the server knows who they are) but does not have permission to access the resource. Return 401 when authentication is missing or expired; return 403 when the user is logged in but lacks the required role or permission.

When should I use 204 No Content?

Use 204 No Content when the request succeeded but there is nothing to send back in the response body. The most common use cases are: successful DELETE requests where the resource has been removed, PUT/PATCH updates where the client already knows the result, and form submissions that do not need to display a confirmation. The response must not include a body. If the client needs confirmation data, use 200 OK with a response body instead.

Can I create custom HTTP status codes?

Technically yes, but it is strongly discouraged. HTTP clients, proxies, CDNs, and monitoring tools only understand standard codes. Custom codes may be misinterpreted or cause unexpected behavior in intermediaries. Instead, use the closest standard code and include specific error details in the response body.