Home/SEO, Domain & Network Inspector Tools/HTTP Status Code Reference & Diagnostic Header Matrix

HTTP Status Code Reference & Diagnostic Header Matrix

Lookup RFC 9110 HTTP status codes, diagnose API response headers, inspect cURL commands, and test live endpoints in real time.

Live Endpoint Probe & Diagnostic Dispatcher

Browser-Native Fetch Engine

Status Code Registry

29 Codes
200

OK

Classification: 2xx Family

RFC 9110 §15.3.1
Caching StanceCacheable by Default
Response BodyPermitted
SpecificationStandard Track

Summary & Specification Context

The HTTP request has succeeded. The actual return payload depends entirely upon the request method used (GET, POST, etc.).

Root Cause / Trigger

Target resource fetched, processed, or mutated without server-side exception or validation failure.

Recommended Remediation

Normal successful operation. Inspect caching headers (ETag, Cache-Control) to optimize delivery performance.

Prescribed RFC Diagnostic Headers

Content-Typeapplication/json; charset=utf-8

Defines serialization mime type

Cache-Controlpublic, max-age=3600, stale-while-revalidate=60

Governs intermediate caching

ETag"33a64df551425fcc55e4d42a148795d9f25f89d4"

Entity validator for conditional GETs

Terminal Reproduction Command (cURL)

curl -i -X GET https://api.example.com/v1/users

HTTP Status Code Taxonomy: Standardized Architecture Under RFC 9110

In web architectures, the Hypertext Transfer Protocol operates as an application-layer request-response protocol. The three-digit status code represents the fundamental signaling mechanism by which servers inform user agents, reverse proxies, and crawlers about the outcome of their request. Formalized initially in RFC 1945 (HTTP/1.0), modernized under RFC 2616 and RFC 7231, and definitively codified in RFC 9110, status codes are divided into five discrete functional blocks:

1xx Informational

Transient handshakes signaling request receipt. They contain only headers terminated by an empty line; no payload body is permitted. Key examples include protocol upgrades (101) and asset preloading via Early Hints (103).

2xx Successful Operations

Confirms the client action was received, understood, and successfully executed. Variants like 201 Created and 204 No Content precisely describe storage mutations without redundant data transfers.

3xx Redirection Directives

Indicates the user agent must perform further action to fulfill the request. Governs search engine index updates, SSL canonicalization, and conditional 304 browser cache validations.

4xx Client Failures

Signals that the client made a syntax, semantic, or authorization error. The server remains healthy, but refuses execution due to bad JSON, missing bearer tokens, or rate limit throttling.

5xx Server Infrastructure Anomalies

The client sent a perfectly valid request, but the server encountered an internal crash, unhandled runtime exception, database connection starvation, or upstream reverse proxy timeout (e.g., NGINX to Node.js / Puma).

The Redirection Matrix: Method Rewriting and Verb Preservation

One of the most frequent architectural pitfalls in modern API design is selecting the wrong redirection status code. Historically, early browsers erroneously rewritten POST requests into GET requests upon receiving 301 and 302 statuses. Modern RFCs resolve this by establishing strict verb preservation:

Status CodePermanenceMethod Preserved?Browser Cache BehaviorPrimary Use Case
301 Moved PermanentlyPermanentNo (Often converts to GET)Aggressive Disk CacheDomain migrations & legacy page SEO
302 FoundTemporaryNo (Often converts to GET)Non-cacheable by defaultTemporary landing or localized routing
307 Temporary RedirectTemporaryStrictly Preserved (POST stays POST)Non-cacheable by defaultAPI server load balancer redirects
308 Permanent RedirectPermanentStrictly Preserved (POST stays POST)Aggressive Disk CacheModern REST API endpoint version deprecation

RFC 9457 & Problem Details: Standardizing Machine-Readable API Errors

Prior to RFC 9457 (which obsoleted RFC 7807), backend engineering teams routinely invented customized JSON error schemas, producing fractured client integration layers. RFC 9457 standardizes the media type application/problem+json with a formal specification schema:

HTTP/1.1 422 Unprocessable Content
Content-Type: application/problem+json
{
  "type": "https://api.twistertools.com/errors/insufficient-funds",
  "title": "Insufficient Account Balance",
  "status": 422,
  "detail": "Your current ledger balance is $12.50, but the checkout transaction requires $45.00.",
  "instance": "/account/transactions/tx_89124a9c",
  "invalid-params": [
    {
      "name": "amount",
      "reason": "Exceeds authorized daily debit cap"
    }
  ]
}

Frequently Asked Questions (FAQ)

What is the primary RFC governing HTTP Status Codes in 2026?

The authoritative standards defining modern HTTP status semantics are RFC 9110 (HTTP Semantics) published in June 2022, which formally obsoleted RFC 7231 and RFC 2616. Additional codes are codified in companion standards such as RFC 6585 (Additional HTTP Status Codes) and RFC 8297 (Early Hints).

What is the critical behavioral difference between HTTP 301 and 308 redirects?

Both 301 Moved Permanently and 308 Permanent Redirect signal permanent resource relocation. However, historically, web browsers rewrote POST requests to GET requests when encountering a 301 redirect. RFC 9110 codified HTTP 308 to strictly prohibit method rewriting; under a 308 redirect, the HTTP verb (POST, PUT, DELETE) and payload body must remain identical upon following.

Why should modern REST APIs use 422 Unprocessable Content instead of 400 Bad Request?

Status 400 Bad Request designates structural or syntax errors where the server cannot parse the byte stream (e.g., malformed JSON). Status 422 Unprocessable Content indicates the syntax is fully valid and parseable, but business logic or semantic constraints failed (e.g., negative balance or missing schema property).

How does HTTP 304 Not Modified optimize browser rendering and CDN costs?

When a client sends conditional request headers like If-None-Match with an ETag or If-Modified-Since with a timestamp, the server responds with 304 without transmitting a body if unchanged. This reduces data egress bandwidth to near-zero and instantly loads assets directly from client cache.

Why does the in-browser sandbox tester return status 0 or CORS errors for some URLs?

Because this tool runs 100% client-side inside your browser for zero latency and privacy, outbound requests are subject to the browser's Cross-Origin Resource Sharing (CORS) security policies. If the destination server does not return 'Access-Control-Allow-Origin', the browser blocks JavaScript from inspecting the HTTP headers.

What is RFC 9457 Problem Details for HTTP APIs?

RFC 9457 defines a standard JSON and XML representation for reporting machine-readable errors from HTTP APIs. Using application/problem+json, responses standardize fields such as 'type', 'title', 'status', 'detail', and 'instance' to prevent ad-hoc error schemas.

Found this tool helpful? Share it with others!

Share on Facebook
Share on X
Share on LinkedIn

Related & Complementary Utilities

Explore more privacy-first client-side web tools.