Ttooleras
📡

HTTP Status Code Reference

Web Tools

Complete reference for every HTTP status code with meaning, usage guidelines, and examples for REST API design.. Free, private — all processing in your browser.

This tool is coming soon. Check back later!

Advertisement

The HTTP Status Codes reference is a complete, searchable catalog of every HTTP response code from 100 (Continue) through 599 with meaning, usage guidelines, and real-world examples. REST API designers, backend developers, DevOps engineers, and support engineers use this reference constantly: deciding which code to return for a specific error, understanding what an upstream service\u2019s response means, documenting API behavior, debugging a confusing 422 response, and so on.

The tool groups codes into the five RFC-defined categories: 1xx informational, 2xx success, 3xx redirection, 4xx client error, 5xx server error. Each code includes the official name (from IANA registry), a plain-English explanation, typical REST API use, recommended response body format, and cross-references to closely related codes (when should you return 422 vs 400 vs 409?). Search by code number, name, or search term to find what you need. Popular codes get expanded examples with full request/response snippets. Everything is based on RFC 9110 (current HTTP specification) plus IANA\u2019s status code registry.

HTTP Status Code Reference — key features

Every registered code

All 60+ officially registered HTTP status codes plus common non-standard ones (418 I’m a Teapot, 451 Unavailable For Legal Reasons).

Plain-English explanation

Each code has a clear description of what it means and when to use it.

Usage recommendations

Guidance on typical REST API patterns — which code is appropriate for validation errors, auth failures, rate limiting, etc.

Related codes

Cross-references between similar codes so you can see the 400 vs 422 distinction, 301 vs 302, and others.

Response body examples

Example JSON error responses following common patterns (RFC 7807 Problem Details, Google API style, simple error).

Search by number or keyword

Find codes by typing the number or searching for what you need (e.g., "rate limit" finds 429).

Category navigation

Browse by 1xx/2xx/3xx/4xx/5xx class for quick reference.

RFC links

Each code links to the relevant RFC section for authoritative reference.

How to use the HTTP Status Code Reference

  1. 1

    Search by code number

    Type 404, 403, or any three-digit code to jump straight to its detail page.

  2. 2

    Or search by keyword

    Type "auth", "rate limit", "timeout" to find relevant codes by concept.

  3. 3

    Read the explanation

    Each code shows what it means, when to use it, and common pitfalls.

  4. 4

    See related codes

    Cross-references help you pick the most specific code for your situation.

  5. 5

    Copy example response

    Grab a ready-to-use JSON error body following the pattern most appropriate for your API.

Common use cases for the HTTP Status Code Reference

API design

  • →Choosing the right code: Deciding between 400 and 422 for a validation error, or 401 and 403 for authorization issues.
  • →API documentation: Drafting API docs that describe each status code your endpoints return with clear meaning.
  • →Error response standardization: Picking an error body format (Problem Details, Google Error, or custom) and applying consistently.

Debugging

  • →Understanding upstream responses: Figuring out what a 502 or 503 from an upstream service actually means and how to handle it.
  • →Client integration: Deciding how to handle each possible status code from a third-party API you’re integrating with.
  • →Webhook handling: Understanding what status codes to return from your webhook receivers to signal success vs retry.

Operations and SRE

  • →Monitoring dashboards: Defining error budgets and alert thresholds by status code category (4xx vs 5xx).
  • →Retry policies: Deciding which codes trigger retries (503, 504, 429) vs not (400, 404).
  • →Incident response: Quickly looking up unfamiliar codes during production incidents.

HTTP Status Code Reference — examples

Successful POST

Creating a resource, returning 201 with Location header.

Input
POST /api/users with new user JSON
Output
HTTP/1.1 201 Created
Location: /api/users/42
Content-Type: application/json

{ "id": 42, "name": "Ana" }

Validation failure

Valid JSON but invalid values — use 422 not 400.

Input
POST /api/users with email missing
Output
HTTP/1.1 422 Unprocessable Content
Content-Type: application/problem+json

{ "type": "https://api.example.com/errors/validation", "title": "Validation failed", "detail": "Email is required", "status": 422 }

Authentication needed

401 with WWW-Authenticate header telling client how to authenticate.

Input
GET /api/private-resource without token
Output
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="api"
Content-Type: application/json

{ "error": "missing_token", "message": "Authentication required" }

Rate limiting

429 with Retry-After telling client when to retry.

Input
GET /api/endpoint (110th request this minute, limit 100)
Output
HTTP/1.1 429 Too Many Requests
Retry-After: 30
Content-Type: application/json

{ "error": "rate_limited", "retry_after": 30 }

Permanent redirect

301 for SEO-friendly permanent move.

Input
GET /old-page
Output
HTTP/1.1 301 Moved Permanently
Location: /new-page
(search engines update indexed links)

Technical details

HTTP status codes are three-digit numeric codes defined by RFC 9110 (HTTP Semantics, 2022, superseding RFC 7231) and registered at IANA. The first digit indicates the class.

1xx (Informational): request received, continuing to process. Rarely used directly — 100 Continue for large uploads, 101 Switching Protocols for WebSocket upgrade, 103 Early Hints for performance.

2xx (Success): request was successful.
- 200 OK: standard success
- 201 Created: resource created (POST often returns this with Location header)
- 202 Accepted: request accepted for async processing
- 204 No Content: success with no response body (PUT, DELETE)
- 206 Partial Content: range request response

3xx (Redirection):
- 301 Moved Permanently: use for SEO-preserving permanent moves
- 302 Found: temporary redirect (method can change)
- 303 See Other: post-redirect-get pattern, client must GET the new location
- 304 Not Modified: cached resource is current
- 307 Temporary Redirect: like 302 but method preserved
- 308 Permanent Redirect: like 301 but method preserved

4xx (Client error):
- 400 Bad Request: generic client error
- 401 Unauthorized: missing or invalid authentication
- 403 Forbidden: authenticated but not allowed
- 404 Not Found: resource does not exist
- 405 Method Not Allowed: HTTP method not supported for resource
- 409 Conflict: request conflicts with current state
- 422 Unprocessable Content: semantic error in valid request (used heavily in APIs)
- 429 Too Many Requests: rate limited

5xx (Server error):
- 500 Internal Server Error: generic server error
- 502 Bad Gateway: upstream service failed
- 503 Service Unavailable: temporarily down (maintenance)
- 504 Gateway Timeout: upstream did not respond in time

Common confusion:
- 401 vs 403: 401 means you need to authenticate (or reauthenticate); 403 means your authenticated identity is not allowed
- 400 vs 422: 400 is for malformed requests; 422 is for valid requests with semantic errors (validation failures)
- 301 vs 302: 301 is permanent (search engines update links); 302 is temporary
- 404 vs 410: 404 means not found (maybe temporary); 410 means gone forever

API error response body: RFC 7807 defines \"application/problem+json\" with standardized fields (type, title, status, detail, instance). Many APIs use simpler formats. Consistency matters more than specifics.

Common problems and solutions

⚠401 vs 403 confusion

Use 401 when authentication is missing or failed (client should retry with credentials). Use 403 when the authenticated user is not allowed (sending credentials again won’t help). Many APIs use them wrong — stick to this semantic.

⚠400 for every error

400 means malformed request. Use 422 for valid requests with semantic errors (validation failure). 400 covers things like malformed JSON; 422 covers things like "this email is required".

⚠200 for errors

Never return 200 with an error body. If something went wrong, use an appropriate 4xx or 5xx status so clients can detect failure without parsing bodies. The only exception is GraphQL, which convention-wise returns 200 with errors in the body.

⚠302 for permanent redirects

Use 301 for permanent moves (search engines will update links). 302 is temporary (engines keep old URL). Using 302 for a move hurts SEO.

⚠404 when 403 is correct

Some APIs hide the existence of resources behind 404 for security (don’t reveal whether a URL exists). But semantically, 403 is correct when the resource exists but the user can’t access it. Document your convention.

⚠Using 500 for client errors

500 means the server hit an error it did not expect. Don’t return 500 for invalid input or authentication failures — use the appropriate 4xx code.

⚠Missing Retry-After on 429/503

429 and 503 should always include a Retry-After header so clients know when to retry. Without it, clients may retry immediately and make the problem worse.

HTTP Status Code Reference — comparisons and alternatives

Compared to the IANA status code registry (authoritative but terse), this tool provides plain-English explanations, examples, and decision guidance. IANA is the canonical source; this is the readable layer on top.

Compared to HTTP status code cat or dog sites (funny meme images), this tool is actually useful for design and debugging. Meme sites are entertaining but unhelpful for picking the right code.

Compared to RFC 9110 directly, this tool is much easier to navigate and includes practical API design guidance. RFC is the specification; this tool is the practitioner\u2019s reference.

Frequently asked questions about the HTTP Status Code Reference

▶What does HTTP 200 mean?

200 OK is the standard success response. The request was received, understood, and processed successfully. Typical for GET responses returning data, PUT responses updating a resource, and idempotent actions. If there is no response body, use 204 No Content instead.

▶When should I use 422 instead of 400?

Use 400 Bad Request when the HTTP request itself is malformed — invalid JSON syntax, missing required headers, wrong HTTP method format. Use 422 Unprocessable Content when the request is syntactically valid but fails semantic validation — a required field is missing, a value is out of range, business rules rejected the request.

▶What is the difference between 401 and 403?

401 Unauthorized means you need to authenticate (or authenticate again). The client should prompt for credentials or re-login. 403 Forbidden means you ARE authenticated but not allowed to access this resource. Re-authenticating won’t help. The 401 name is historically confusing — it should have been "Unauthenticated" but the name is fixed by RFC.

▶Which redirect code should I use for permanent moves?

301 Moved Permanently for SEO-critical permanent moves. Search engines update their indexed URLs when they see 301. 308 Permanent Redirect is newer and preserves the HTTP method (301 historically could change POST to GET on redirect, though modern behavior usually preserves the method). Use 308 if you need guaranteed method preservation, 301 for backward compatibility and SEO.

▶What does 504 Gateway Timeout mean?

The server you connected to (typically a reverse proxy or load balancer) did not receive a response from an upstream service within a timeout period. It is a 5xx server error, not a client problem. Retrying may work; investigating upstream health is the actual fix.

▶Can I use custom status codes?

HTTP allows only registered codes from IANA. Custom codes cause undefined behavior in clients and proxies. Always use a registered code and carry custom information in the response body. Non-standard codes like 418 I’m a Teapot exist but are explicitly an RFC joke — don’t use them in production.

▶What is RFC 7807 Problem Details?

RFC 7807 defines a standard format for machine-readable error responses with fields like type (URI identifying the error), title (short human-readable name), status (HTTP status code), detail (specific error message), and instance (URI for this specific occurrence). Use it for consistent API error responses.

▶Does GraphQL use HTTP status codes?

GraphQL convention is to return 200 OK with errors in the response body, regardless of whether the query succeeded. This is because GraphQL can have partial successes (some fields resolve, others error). However, 400 is appropriate for malformed GraphQL queries, and 401/403 for auth issues before the query is even parsed.

Additional resources

Advertisement

Related tools

All Web Tools
🔌

API Request Builder

Build and test HTTP API requests with method, headers, body, authentication, and query parameters — inspect full response in your browser.

💻

cURL to Code Converter

Convert cURL commands to equivalent code in Python (requests), JavaScript (fetch), PHP, Go, Ruby, Node, and other languages.

🔐

Hash Generator

Generate MD5, SHA-1, SHA-256, SHA-512 hashes for text and files

📋

HTTP Headers Lookup

Complete reference for HTTP request and response headers with usage examples, RFC references, and common values.

📡

HTTP Status Code Lookup

Quick lookup tool for HTTP status codes — enter any status number and get the meaning, category, and usage guidelines instantly.

{}

JSON Formatter

Format, validate, and beautify JSON instantly in your browser

Learn more

Next.js App Router: A Complete Beginner Tutorial

26 min read

How to Decode a JWT: A Practical Debugging Guide (with the Base64URL Gotcha Nobody Warns You About)

17 min read

UUID v4 vs v7: The Default Has Quietly Changed

22 min read

Explore more tools

200+ free tools that run in your browser.

Browse all tools →