Reference for all HTTP status codes
Quick CTA
Search a status code or keyword first to find the right HTTP status and copy the status line immediately; scenario guidance stays in Deep.
Next step workflow
Deep expands pitfalls, recipes, snippets, FAQ, and related tools when you need troubleshooting or deeper follow-through.
A complete searchable reference for all HTTP status codes. Filter by category (1xx informational, 2xx success, 3xx redirect, 4xx client error, 5xx server error) or search by code number and description. Each code includes a detailed explanation and real-world usage examples.
404
Use it when the resource is missing or unknown.
410
Use it when the resource is intentionally gone and will not return.
Note: Both are not-found style responses, but 410 communicates a stronger permanence signal.
Business payload only
Use only in legacy environments that cannot change status handling.
Correct transport status + payload
Use for modern APIs and observable client behavior.
Note: HTTP status should represent transport semantics, not be hidden in JSON fields.
Generic 500 fallback
Use only during emergency stabilization windows.
Precise status mapping
Use as standard API contract behavior.
Note: Precise mapping improves retry logic, UX messages, and incident triage speed.
Selective retry policy
Use when semantics indicate temporary limits or transient unavailability.
Blind retry policy
Avoid for validation errors and business-rule rejections.
Note: Retry decisions should follow status semantics, not one global switch.
Fast pass
Use for low-impact exploration and quick local checks.
Controlled workflow
Use for production delivery, audit trails, or cross-team handoff.
Note: Http Status Codes is more reliable when acceptance criteria are explicit before release.
Direct execution
Use for disposable experiments and temporary diagnostics.
Stage + verify
Use when outputs will be reused by downstream systems.
Note: Staged validation reduces silent compatibility regressions.
Bad input: Client sends malformed field but server responds with HTTP 500.
Failure: Clients retry needlessly and alerting treats user errors as server outages.
Fix: Map client-correctable input errors to 400/422 with actionable details.
Bad input: Auth failure response: {"ok": false, "reason": "unauthorized"} with 200.
Failure: SDKs treat request as success and skip token refresh logic.
Fix: Return 401/403 consistently so middleware and clients behave correctly.
Bad input: Alert rule marks every 4xx and 5xx as same severity incident.
Failure: Ops team chases client-side mistakes while real server faults grow.
Fix: Split alert channels by status family and enforce distinct runbooks.
Bad input: Input policy differs between environments.
Failure: Output appears valid locally but fails during downstream consumption.
Fix: Normalize contracts and enforce preflight checks before export.
Bad input: Compatibility assumptions remain implicit and drift over time.
Failure: Same source data yields inconsistent outcomes across environments.
Fix: Declare compatibility constraints and verify with an independent consumer.
Q01
Because 301 vs 302, 401 vs 403, or 404 vs 410 mistakes are common under delivery pressure.
Q02
No. The exact code changes caching, client behavior, and debugging expectations.
Recommend: Use 4xx codes with explicit remediation hints.
Avoid: Avoid 5xx for request-shape or permission issues.
Recommend: Use 5xx + retry guidance and observability correlation IDs.
Avoid: Avoid returning 200 with hidden error flags.
Recommend: Separate contract regressions (4xx) from runtime capacity faults (5xx) before mitigation.
Avoid: Avoid one-size-fits-all rollback decisions based only on total error rate.
Recommend: Use fast pass with lightweight verification.
Avoid: Avoid promoting exploratory output directly to production artifacts.
Recommend: Use staged workflow with explicit validation records.
Avoid: Avoid one-step execution without replayable evidence.
Cause: Broad server errors hide meaning from clients and from your own team.
Fix: Choose the most accurate status that reflects the actual failure class.
Goal: Look up what a status code means before locking response behavior or documentation.
Result: You reduce the chance of using a status code that sends the wrong signal.
Goal: Prioritize release incidents by quickly mapping logs to 4xx/5xx ownership paths.
Result: Incident owners avoid cross-team confusion and restore faster.
Goal: Validate assumptions before output enters shared workflows.
Result: Delivery quality improves with less rollback and rework.
Goal: Convert recurring failures into repeatable diagnostics.
Result: Recovery time drops and operational variance shrinks.
http
HTTP/1.1 404 Not FoundCorrect status codes reduce client complexity. Many integration bugs come from semantically wrong status usage, not payload issues.
Use 2xx for successful outcomes, 4xx for client-correctable issues, and 5xx for server faults that clients cannot fix.
Differentiate 400, 401, 403, 404, and 422 clearly to improve retry and error-handling behavior.
Document status code contracts in API docs and enforce them in contract tests.
When changing status semantics, version the endpoint or provide a transition window to avoid breaking clients.
HTTP Status Codes is most reliable with real inputs and scenario-driven decisions, especially around "Client can fix request and retry manually".
401 Unauthorized means authentication is required and has failed or not been provided. 403 Forbidden means the server understood the request but refuses to authorize it — the user is authenticated but lacks permission.
301 is a permanent redirect, telling browsers and search engines to update their records. 302 is temporary, meaning the original URL should be kept. For SEO, 301 passes link equity while 302 does not.
Use 400 for malformed requests (invalid JSON syntax). Use 422 for requests that are syntactically valid but semantically wrong — such as failing business logic validation like an invalid email format.
Yes, but you should still validate output in your real runtime environment before deployment. HTTP Status Codes is designed for fast local verification and clean copy-ready results.
Yes. All processing happens in your browser and no input is uploaded to a server.
Use well-formed input, avoid mixed encodings, and paste minimal reproducible samples first. Then scale to full content after the preview looks correct.