HTTP Status Codes

Search HTTP status codes and review concise response semantics.

HTTP Status Codes

200 OK

Request succeeded.

201 Created

A new resource was created.

204 No Content

Request succeeded with no response body.

301 Moved Permanently

Resource moved to a new URL.

302 Found

Temporary redirect response.

400 Bad Request

Malformed client request.

401 Unauthorized

Authentication required.

403 Forbidden

Authenticated but not permitted.

404 Not Found

Resource was not found.

409 Conflict

Request conflicts with current state.

422 Unprocessable Entity

Validation failed.

429 Too Many Requests

Rate limit exceeded.

500 Internal Server Error

Unexpected server failure.

502 Bad Gateway

Invalid upstream response.

503 Service Unavailable

Server temporarily unavailable.

What This Tool Does

  • Hypertext Transfer Protocol (HTTP) status codes are three-digit integers returned by servers to indicate the outcome of an HTTP request. Standardized in core HTTP specifications (including RFC 7231 and RFC 9110), these codes are divided into five classes: Informational (1xx), Successful (2xx), Redirection (3xx), Client Error (4xx), and Server Error (5xx). They serve as the universal language for API integrations, web browsers, and search crawlers to understand request states.
  • In modern web development, selecting and interpreting the correct status code is crucial for error handling, SEO indexing, and caching behavior. For example, returning a generic 200 OK status for a failed API response (containing an error message in the payload) is a common anti-pattern that breaks client-side error handling. Similarly, choosing between a 301 Moved Permanently and a 302 Found redirect tells search engines whether to transfer link equity (SEO value) to the new URL.
  • The HTTP Status Codes search tool on ScriptPulse.tools serves as an interactive reference guide. Developers can search status codes, look up reason phrases, and review official semantics. Running entirely client-side, the tool helps engineers debug API responses, configure server routing, and verify error-handling boundaries during local development.

How It Works

  • The status codes tool uses a built-in dictionary containing all standardized IANA HTTP status codes and their descriptions.
  • Users can search by entering three-digit codes (e.g. 404) or search terms (e.g. "not found" or "gateway").
  • The tool filters the dictionary in real time, displaying the code class, standard reason phrase, official definition, and typical debugging suggestions.
  • It highlights common status relationships (like 401 Unauthorized vs 403 Forbidden) and explains caching implications for each code.

Usage

  1. Enter the HTTP status code (e.g., 429) or code name (e.g., too many requests) in the search field.
  2. The tool displays matching status codes with their standard reason phrases and definitions instantly.
  3. Review the code details, including typical causes, caching settings, and API implementation recommendations.
  4. Copy code descriptions or definitions to include in your API documentation or code comments.
  5. Reference related status codes listed in the related slug panel.

Examples

  • 401 Unauthorized vs 403 Forbidden — Reviewing the distinct roles of authentication (401) and authorization (403) states.
  • 301 Permanent Redirect — Verifying SEO behavior for permanent URL migrations.
  • 429 Too Many Requests — Checking standard API rate-limiting response setups.
  • 503 Service Unavailable — Documenting retry header behaviors (Retry-After) during server maintenance.
  • 410 Gone — Signaling search crawlers that a resource is permanently deleted and should be removed from indexes.

Real-World Use Cases

  • Designing API error-handling schemas by selecting standard HTTP status codes for validation errors or resource limits.
  • Configuring redirect rules in server configs (like Nginx rewrite or Apache .htaccess) with correct status codes.
  • Troubleshooting client API integrations by looking up unknown status codes found in system error logs.
  • Auditing crawler behavior by checking how search engine indexers handle status codes like 410 Gone or 503 Service Unavailable.
  • Educating junior engineers on the difference between client-side (4xx) and server-side (5xx) execution failures.

Best Practices

  • Always return standard HTTP status codes that accurately reflect the outcome of the request.
  • Return detailed error messages inside client-error payloads (4xx) to help developers diagnose validation failures.
  • Set appropriate caching headers for redirection codes to prevent browsers from caching temporary redirects.
  • Include a Retry-After header when returning 429 Too Many Requests or 503 Service Unavailable to guide client retry intervals.
  • Log server-side errors (5xx) with high priority in monitoring systems to capture application failures immediately.

Common Mistakes

  • Returning 200 OK for API responses containing error payloads, which prevents client libraries (like Axios or Fetch) from triggering catch blocks.
  • Using the wrong redirect code: using a 302 Found (temporary) when a 301 Moved Permanently is needed, causing search engines to ignore index updates.
  • Confusing 502 Bad Gateway and 504 Gateway Timeout: 502 indicates an invalid response from upstream, while 504 indicates the upstream server timed out.
  • Ignoring standard status codes and inventing custom codes (like 600), which breaks standard web proxy and firewall filtering.
  • Returning 500 Internal Server Error for client validation errors (like missing fields) instead of 400 Bad Request.

Limitations

  • Results should be validated in your target runtime before production use.
  • Extremely large input payloads may be constrained by browser memory and performance limits.

Technical Reference Guide

  • RFC 9110 (Section 15): The current standard defining HTTP status codes, classes, caching rules, and registry procedures.
  • Class Ranges: 1xx (Informational), 2xx (Success), 3xx (Redirection), 4xx (Client Error), 5xx (Server Error).
  • Caching Rules: Codes like 200, 301, and 404 are cacheable by default, whereas codes like 201, 302, and 500 are not cached.

FAQ

  • What is the difference between 401 Unauthorized and 403 Forbidden?

    401 Unauthorized means the request lacks valid authentication credentials. The client must authenticate to access the resource. 403 Forbidden means the client is authenticated but does not have permission to access the resource.

  • When should I use a 301 redirect instead of a 302 redirect?

    Use 301 Moved Permanently when a page has permanently moved and you want search engines to transfer link equity to the new URL. Use 302 Found (temporary) when a page is temporarily relocated, telling crawlers to retain the original URL index.

  • What is a 429 status code?

    429 Too Many Requests indicates that the user has sent too many requests in a given amount of time (rate limited). Servers should include a Retry-After header indicating how long the client must wait.

  • What causes a 502 Bad Gateway error?

    A 502 Bad Gateway error occurs when a gateway or proxy server (like Nginx) receives an invalid response from the upstream application server (like Node.js or Python) that it attempted to contact.

  • Is it acceptable to return custom status codes?

    No. Custom status codes (e.g., 499 or 599) should be avoided. Standard HTTP clients and proxies do not understand them, and they can cause intermediate network nodes to fail.

  • What does 409 Conflict mean?

    409 Conflict indicates that the request conflicts with the current state of the server. This is common when attempting to register a username that already exists or submit conflicting edits.

  • Are all HTTP status codes cacheable?

    No. Caching behavior is defined per status code. For example, 200 OK and 301 Moved Permanently are cacheable by default, while 204 No Content and server errors (5xx) are not cached.

  • What is the meaning of 418 I'm a teapot?

    418 I'm a teapot is an RFC-defined easter egg status code (RFC 2324) introduced as an April Fools joke in 1998. It is not intended for real-world web API operations.

Related Tools

Explore related utilities inside the Web Studio workshop for complementary engineering workflows.

View all Web Studio tools