HTTP Status Inspect

What does this tool do?

Interpret HTTP status codes (e.g., 200/301/404/500) and organize their meaning and related headers to check.

Useful for diagnosing cases like “why 200 but not working?” or “where is 301/302 redirecting?”

Basics (role of status codes)

• HTTP status codes indicate the outcome of a request.
• Codes are 3 digits; the first digit indicates the class (1xx–5xx).
• Meanings can vary by context, so related headers matter.

Status classes (quick)

• 1xx: Informational (in progress)
• 2xx: Success (processed)
• 3xx: Redirection (move to another URL)
• 4xx: Client issues (invalid request, etc.)
• 5xx: Server issues (processing failed)

Input examples

• HTTP/1.1 404 Not Found
• HTTP/2 301 Moved Permanently
• Status: 503
• Paste full Response Headers

Redirects (3xx) key points

• The Location header indicates the next URL.
• 301/308 are permanent; 302/307/303 are temporary.
• Loops/multi-hop redirects can be checked with Redirect Chain Inspect.

Caching (304 / cache validation)

304 Not Modified signals no change and is used with ETag / Last-Modified.

• Check ETag/If-None-Match and Last-Modified/If-Modified-Since
• Cache-Control/Expires can prevent 304 behavior

How to read a status line (HTTP/1.1 404 Not Found)

• HTTP/1.1: protocol version (tools may display HTTP/2 or HTTP/3).
• 404: status code (class is the first digit).
• Not Found: reason phrase (can be omitted).

You may also see lines like Status: 404 when pasting headers; treat it as status information as well.

Distinguishing 4xx vs 5xx (quick)

4xx is generally “request-side issue”, 5xx is “server failed to process”, but intermediaries can change what you see.

• Even 4xx can be server-side misconfig (e.g., 401/403 due to auth or CORS policy).
• 502/504 often point to an upstream issue: CDN/reverse proxy/app boundaries matter.

Auth/authz (401/403) key points

• 401: authentication required/failed. Check WWW-Authenticate.
• 403: authenticated but forbidden (insufficient privileges/policy).
• With cookies/JWT, also verify they are sent and not expired/invalid.

Methods (405/OPTIONS) key points

• 405 Method Not Allowed typically includes an Allow header listing permitted methods.
• If CORS preflight (OPTIONS) returns 4xx/5xx, browsers block before the actual request.

Rate limiting / temporary outage (429/503)

• 429 Too Many Requests often means “too many in a short time”.
• 503 Service Unavailable means “temporarily unable to handle” (maintenance/overload/upstream).
• Retry-After (if present) indicates when to retry.

When to suspect 502/504 (gateway/upstream)

With CDNs/reverse proxies, the status you see may be generated by an intermediary.

• 502: invalid response from upstream (connect failure/crash/protocol mismatch).
• 504: timed out while waiting for upstream.
• Use Via/Age/Server/Forwarded-family headers to infer the path.

Symptom-based checks (for quick troubleshooting)

• “API is 200 but UI breaks”: check Content-Type and body (JSON error vs HTML error).
• “Only POST fails”: suspect 405/415/413; check Allow/Content-Type/Content-Length.
• “Only prod loops on 301”: check Location and redirect chain (http↔https, www).
• “Intermittent 502/504”: check upstream load/timeouts and whether a CDN is involved (Via/Age).

Recommendations (practical)

• For 4xx check input/auth/routing first; for 5xx suspect upstream/timeouts first
• Do not judge by status alone; always inspect related headers like Location/WWW-Authenticate/Retry-After
• Reproduce with curl/server logs to eliminate browser-specific behavior

Next action by code class

• 2xx: verify body and Content-Type to confirm semantic success
• 3xx: check Location target, loops, and method-preservation behavior
• 4xx: inspect inputs, credentials, CORS/CSRF, and allowed methods
• 5xx: inspect upstream connectivity, timeouts, and retry strategy

Common pitfalls

• 200 OK with an error page in the body
• 401 without WWW-Authenticate header
• 405 without Allow header
• 429/503 without Retry-After, making retry timing unclear
• 404 can be caused by routing/rewrites/permissions, not only missing URLs.
• 502/504 is often an intermediary/upstream issue rather than the app itself.

Debugging workflow (recommended)

• Extract full headers with Response Headers Parser
• Use this tool to summarize status meaning and related headers
• Deep dive into Location/Cache-Control/ETag with dedicated tools

Related tools

• Response Headers Parser
• Location Inspect
• Redirect Chain Inspect
• Cache-Control Inspect
• ETag Inspect
• Last-Modified Inspect
• Expires Inspect
• Vary Inspect
• Content-Type Inspect
• Via Inspect
• Age Inspect
• Forwarded Inspect
• CORS Response Inspect

What this tool does

• Classify and explain HTTP status codes
• Highlight related headers to verify (Location/ETag/Allow, etc.)
• List multiple status lines if present

Operational notes

• Intermediaries may rewrite headers. Compare captures from equivalent points.
• Confirm final decisions with server logs and configuration such as trusted proxy and routing.

Referenced specs

• RFC 9110 (HTTP Semantics)
• RFC 9111 (HTTP Caching)
• MDN: HTTP response status codes

FAQ

References

1. RFC 9110
2. RFC 9111
3. MDN: HTTP response status codes
4. MDN: Location
5. MDN: WWW-Authenticate
6. MDN: Retry-After
7. RFC 6585 (additional status codes including 429)

Next to view (diagnostic order)

These links are generated from site_map rules in recommended diagnostic order.

1. Retry-After Inspect — Parse Retry-After and inspect retry wait behavior
2. Response Headers Parser — Parse response headers into structured data
3. Location Inspect — Parse Location header and split destination URL
4. Redirect Chain Inspect — Analyze redirect chains to detect loops and waste hops
5. How to Diagnose Retry Storms on 429/503 — Isolate Retry-After parsing and client implementation gaps to stop excessive retries
6. How to Diagnose JS/CSS Blocks from nosniff Mismatch — Trace Content-Type vs nosniff mismatches, fallback responses, and delivery-layer rewrites
7. How to choose response header tools — Map Retry-After, Server-Timing, Link, Content-Type, and nosniff checks by symptom
8. HTTP Header Parser — Parse raw headers into structured lists

Same-theme links

Response Header Diagnostics

Step through raw headers to inspect Retry-After, Server-Timing, Link, and Content-Type

• HTTP Header Parser — Parse raw headers into structured lists
• Response Headers Parser — Parse response headers into structured data
• Set-Cookie Inspect — Parse Set-Cookie attributes and review delivery policy
• Cookie Domain/Path Matcher — Evaluate cookie send conditions by Domain/Path/Secure
• SameSite Cookie Simulator — Simulate cookie send behavior from SameSite and request context
• Set-Cookie Conflict Checker — Detect same-name cookie conflicts and overwrite risks
• Cookie Size Checker — Estimate Cookie header size and check limit risks
• Retry-After Inspect — Parse Retry-After and inspect retry wait behavior
• Server-Timing Inspect — Parse Server-Timing and inspect latency metrics
• Link Header Inspect — Parse Link headers and inspect rel/as/type
• Content-Type Inspect — Parse Content-Type and inspect MIME/charset
• X-Content-Type-Options Inspect — Parse X-Content-Type-Options and validate nosniff

Redirects

Use status codes and Location chains to isolate redirect issues

• Location Inspect — Parse Location header and split destination URL
• Redirect Chain Inspect — Analyze redirect chains to detect loops and waste hops