HTTP Status Analyzer

Server assisted Validation

Paste a raw response (or fetch a public URL) to see the status class, semantics, required headers for that status (Location, Retry-After, WWW-Authenticate, Allow) and common mistakes.

Privacy: Processing happens in your browser where possible. Network checks are relayed through the Mutqan backend and are not stored.

What are HTTP status codes?

An HTTP status code is the three-digit number a server returns with every response to say how the request went: 2xx success, 3xx redirection, 4xx a client-side problem (400 bad request, 401 unauthenticated, 403 forbidden, 404 not found, 429 too many requests), 5xx a server-side failure. The meanings are defined in RFC 9110 and RFC 6585, and an API that uses them precisely is far easier to test and to monitor.

Read the guide: HTTP Status Codes Explained

How to use HTTP Status Analyzer

  1. Paste the raw HTTP response (status line, headers, blank line, body) or curl -i output — or switch to fetch mode and enter a public URL.
  2. If your paste has no status line, enter the code in the status field.
  3. Click "Analyze" to read the semantics, body and caching expectations for that status.
  4. Review the findings and companion-header table; fix the errors first, then the warnings.

HTTP Status Analyzer features

  • Explains the status class, meaning, typical use and testing hints for any code 100–599
  • Checks companion headers per status: Location, WWW-Authenticate, Allow, Retry-After, Content-Range, Proxy-Authenticate
  • Flags bodies on 204/304, missing Content-Type, invalid Retry-After, cacheable 5xx errors and JSON bodies that do not parse
  • Spots method/status mismatches such as 301 after POST or 200 with Location after a create
  • Accepts raw responses, curl -i output, header lists or a JSON object; or fetches a public URL without following redirects
  • Verdict (correct / questionable / incorrect) with a downloadable findings table

HTTP Status Analyzer example

401 without a challenge

Input:

HTTP/1.1 401 Unauthorized
Content-Type: text/html
Cache-Control: max-age=3600

Output:

Status: 401 Unauthorized (client error) · Verdict: Incorrect
High — WWW-Authenticate: 401 Unauthorized requires a WWW-Authenticate header. RFC 9110 requires at least one challenge.
Low — Content-Type: Error responses from APIs are easier to consume as application/problem+json.

Frequently asked questions about HTTP Status Analyzer

Which headers are required for which status?

301/302/303/307/308 need Location, 401 needs WWW-Authenticate, 405 needs Allow, 407 needs Proxy-Authenticate and 206 needs Content-Range. 429 and 503 should send Retry-After.

What input formats work?

A raw HTTP response (status line, headers, blank line, body), curl -i output, plain "Name: value" lines with the status code entered separately, or a JSON object with status and headers.

Does fetch mode follow redirects?

No — it returns the first response so you can inspect the redirect status and its Location header. The URL must be public.

Why does it complain about a body on 204?

RFC 9110 forbids a message body on 1xx, 204 and 304 responses; many clients fail or hang when one is present.

What is the difference between 401 and 403?

401 means authentication is missing or invalid and must include a WWW-Authenticate challenge; 403 means the caller is known but not allowed, so no challenge is needed.

Technical notes

Status semantics come from the shared HTTP knowledge base (RFC 9110 plus common vendor codes). Companion headers the analyzer treats as required produce high-severity findings, recommended ones low-severity notes. "Required" covers the RFC 9110 MUSTs (WWW-Authenticate on 401, Allow on 405, Proxy-Authenticate on 407, Content-Range on a single-part 206) and Location on 301, 302, 303, 307 and 308: RFC 9110 phrases it as SHOULD for 301, 302, 307 and 308 and defines 303 in terms of the Location URI, and without it a client cannot follow the redirect. ETag on 304 is only a note, because RFC 9110 requires it only when a 200 response would have carried one.

In fetch mode the relay is asked not to follow redirects so that a 301/302 and its Location header are analysed as returned; the relay still refuses private and loopback addresses.

References