HTTP Status Code Lookup

The HTTP Status Code Lookup provides instant access to detailed explanations for every HTTP response status code from 100 to 599, including RFC references, common use cases, and the subtle distinctions between frequently confused codes. Enter a code like 403 or search by keyword like "redirect" to get the official name, meaning, and practical guidance for when to use it in your own APIs.

Understanding HTTP Status Codes

Every HTTP response begins with a three-digit status code that tells the client what happened with its request. If you have ever seen a 404 page, received a 500 error from an API, or been silently redirected by a 301, you have encountered status codes in action. They are the first thing your browser, HTTP client, or monitoring system checks when a response arrives, and choosing the right code in your own APIs is essential for building systems that behave predictably and are easy to debug.

Status codes are grouped into five classes by their first digit. The 1xx codes are informational -- the server is acknowledging the request but has not finished processing it. The 2xx codes indicate success -- the request was received, understood, and processed correctly. The 3xx codes handle redirects -- the client needs to take additional action, usually following a new URL. The 4xx codes signal client errors -- the request was malformed, unauthorized, or pointed at something that does not exist. And the 5xx codes indicate server errors -- the server understood the request but failed to process it due to an internal problem.

The challenge is not knowing that 200 means success or 404 means not found -- those are well known. The real complexity is in the subtle distinctions. Should you use 401 or 403 when a user lacks permission? Is 301 or 308 the right redirect for a POST endpoint that has moved? Should a search with no results return 200 with an empty body, 204, or 404? This tool explains these distinctions with practical guidance so you can make the right choice for your specific use case.

How to Look Up an HTTP Status Code

1. Enter a status code number (e.g., 404) or search by keyword (e.g., "redirect", "unauthorized").
2. View the official name, RFC reference, and detailed explanation.
3. Read use-case guidance for when to return that code in your own API.

HTTP Status Code Quick Reference

Informational (1xx)

Success (2xx)

Redirection (3xx)

Client Error (4xx)

Server Error (5xx)

Commonly Confused Status Codes

301 vs. 302 vs. 307 vs. 308

• 301 Moved Permanently -- Use when a resource's URL has changed forever. Browsers and search engines may change POST to GET on redirect.
• 302 Found -- Temporary redirect. Historically, browsers changed POST to GET despite the spec saying they should not. Ambiguous in practice.
• 307 Temporary Redirect -- Like 302, but the browser must preserve the original HTTP method (POST stays POST).
• 308 Permanent Redirect -- Like 301, but the browser must preserve the original HTTP method. Use this instead of 301 when redirecting form submissions.

401 vs. 403

• 401 Unauthorized -- The client has not provided valid authentication credentials. The response should include a WWW-Authenticate header indicating the expected authentication scheme.
• 403 Forbidden -- The client is authenticated (or authentication is not required), but does not have permission to access the resource. Re-authenticating will not help.

404 vs. 410

• 404 Not Found -- The resource is not available. It may have never existed, or it may exist in the future.
• 410 Gone -- The resource existed previously but has been intentionally and permanently removed. Search engines will deindex the URL faster with 410 than 404.

500 vs. 502 vs. 503 vs. 504

• 500 -- The server itself encountered an error processing the request (unhandled exception, bug).
• 502 -- A reverse proxy or load balancer received an invalid response from an upstream server.
• 503 -- The server is temporarily unable to handle requests (overloaded, in maintenance). Often includes a Retry-After header.
• 504 -- A reverse proxy or load balancer timed out waiting for an upstream server response.

When to Use This Tool

• Designing RESTful APIs -- Choose semantically correct status codes for each endpoint and error condition.
• Debugging API responses -- Understand what an unfamiliar or unexpected status code means in server logs.
• Handling redirects -- Determine whether to use 301, 302, 307, or 308 for your specific redirect scenario.
• Configuring monitoring alerts -- Set up alerts for specific status codes with an understanding of what each one indicates.
• SEO optimization -- Use the correct redirect codes (301 vs 302) to preserve search engine rankings during URL migrations.
• Incident triage -- Quickly identify whether a 5xx error is coming from your application (500) or from infrastructure (502, 504).

Practical Guidance for API Status Codes

One of the most common API design mistakes is overusing 200 OK for everything, including errors. Some APIs return 200 with an error message in the body, forcing the client to parse the response to determine whether the request actually succeeded. This breaks standard HTTP tooling, makes monitoring unreliable, and confuses developers who expect HTTP status codes to reflect the actual outcome. Use 200 for success, 4xx for client errors, and 5xx for server errors -- that is what the codes are for.

Another frequent source of confusion is the choice between 404 and empty success responses. If a user searches for products and the search returns zero results, the correct response is 200 with an empty array -- the search endpoint exists, it worked, and it found nothing. If the user requests a specific product by ID and that product does not exist, the correct response is 404 -- the resource they asked for is not there. The distinction is between "I did what you asked and the answer is nothing" (200) versus "the thing you asked about does not exist" (404).

For APIs that serve both authenticated and unauthenticated users, be careful about the information you leak through status codes. Responding with 403 to an unauthorized request for /admin/users confirms that the endpoint exists. Responding with 404 instead reveals nothing about your URL structure. The security community calls this "security through obscurity" and it has limits, but it is a reasonable defense-in-depth measure for sensitive endpoints.

Frequently Asked Questions

What are CloudFlare's custom 5xx status codes?

CloudFlare uses codes 520 through 527 for issues between their edge servers and origin servers. For example, 520 means the origin returned an unexpected response, 521 means the origin web server is down, 522 means the connection to the origin timed out, and 524 means the origin responded but took too long.

Is there a difference between "Unauthorized" and "Unauthenticated"?

Technically, HTTP 401 should be called "Unauthenticated" because it means the client has not proven their identity. The name "Unauthorized" is a historical misnomer in the spec. True authorization failure (you are authenticated but lack permission) is 403 Forbidden.

Should I use 404 or 204 when a search returns no results?

Use 200 with an empty result set. The resource (the search endpoint) exists and responded successfully -- it just found no matching items. Reserve 404 for when the endpoint itself does not exist.

When should I use 429 Too Many Requests?

Use 429 when a client has exceeded your API's rate limit. Include a Retry-After header indicating how many seconds the client should wait before retrying. Also include X-RateLimit-Limit and X-RateLimit-Remaining headers so clients can see their current quota status without hitting the limit.

What is the difference between 502 and 504 in a reverse proxy setup?

A 502 Bad Gateway means the proxy received a response from the upstream server, but the response was invalid or malformed (for example, the upstream returned garbage data or closed the connection mid-response). A 504 Gateway Timeout means the proxy never received a response at all -- the upstream server did not reply within the configured timeout period. Both indicate upstream problems, but 504 typically suggests the upstream is overloaded or unreachable, while 502 suggests it is responding but behaving incorrectly.

Should I return 201 Created or 200 OK after creating a resource?

Use 201 Created for POST requests that create a new resource. Include a Location header pointing to the newly created resource's URL. This follows REST conventions and helps clients locate the new resource without parsing the response body. Use 200 for updates to existing resources (PUT/PATCH).

Related Tools

• HTTP Header Formatter - Parse and format HTTP response headers that accompany status codes
• CORS Header Explainer - Understand CORS errors that produce specific status codes
• MIME Type Lookup - Look up Content-Type headers returned with HTTP responses
• Cookie Header Parser - Parse Set-Cookie headers from HTTP responses
• curl Command Builder - Build curl commands to test endpoints and inspect status codes