HTTP Status Code Reference

Searchable reference for all HTTP status codes — with meaning, common causes, and fix recommendations.

Last updated: March 25, 2026

informational

success

redirection

client error

server error

Client-Side Processing

Input Data Stays on Device

Instant Local Execution

Find this tool useful? Support the project to keep it free!

Buy me a coffee

What is HTTP Status Code Reference?

HTTP status codes are standardized 3-digit numbers returned by web servers in response to every HTTP request. They tell the client (browser, API consumer, mobile app) whether the request succeeded, failed, or requires further action. Status codes are defined by IANA and specified in RFC 9110 (the current HTTP semantics standard), with additional codes registered for specific use cases.

Understanding status codes deeply — beyond knowing that "404 = not found" and "500 = server error" — is essential for building reliable APIs, debugging network issues, and implementing correct error handling. The difference between a 401 (Unauthenticated) and a 403 (Unauthorized) has real security implications. Choosing between 200 and 204 for an API response that has no body is a design decision that affects clients. This reference provides the meaning, correct usage, and common causes for every code in the HTTP standard.

How to Use HTTP Status Code Reference

Search by code number (e.g., "404") or by keyword (e.g., "redirect", "forbidden", "timeout")

Browse by category using the tabs: 1xx Informational, 2xx Success, 3xx Redirection, 4xx Client Error, 5xx Server Error

Click any code to expand its full description, common causes, and recommended actions

Use the filter to show only codes relevant to REST APIs, browser behavior, or server errors

Common Use Cases

Looking up the exact meaning of an unfamiliar HTTP code returned by a third-party API
Deciding which status code to return from a REST API endpoint for different scenarios
Debugging a web application that returns unexpected redirect loops or authentication errors
Understanding Nginx and Apache error logs that contain HTTP status codes
Learning HTTP semantics while building a web framework or API client library
Implementing correct error handling in a frontend app based on response status codes
Choosing between 200/201/204/400/401/403/404/422 for a specific API design decision
Debugging CDN or proxy issues where caching behavior depends on response status codes

Example Input and Output

A cheat sheet of the most commonly confused HTTP status code pairs:

Status code

200 vs 201 vs 204
401 vs 403
404 vs 410
422 vs 400
301 vs 302 vs 307

Meaning and when to use it

200 OK: Request succeeded, body contains the result
201 Created: POST succeeded, new resource was created (use with Location header)
204 No Content: Request succeeded, no body to return (e.g. DELETE)

401 Unauthorized: Not authenticated — user must log in first (name is misleading)
403 Forbidden: Authenticated but not permitted — user is logged in but lacks access

404 Not Found: Resource doesn't exist (or you're hiding it for security)
410 Gone: Resource existed but was permanently deleted (stronger SEO signal than 404)

422 Unprocessable Entity: Validation error — syntax ok, but semantics failed (REST APIs)
400 Bad Request: Malformed request syntax — the client sent invalid HTTP

301 Moved Permanently: Permanent redirect (browser + SEO caches indefinitely)
302 Found: Temporary redirect (originally "Moved Temporarily", browsers reuse GET)
307 Temporary Redirect: Temporary redirect, preserves HTTP method (POST stays POST)

Client-Side Reference

This is a client-side reference tool — no lookups or queries are sent to our servers. All code data is bundled locally in the application.

REST API Design Tip

Be consistent with your status codes across your entire API. Pick your conventions for validation errors (400 vs 422), successful creation (200 vs 201), and empty responses (200 with null vs 204), document them in your API spec (OpenAPI), and apply them everywhere uniformly.

CDN and Caching Behavior

CDNs (Cloudflare, Fastly, CloudFront) have specific caching behaviors per status code: 200, 301, 404 are cached by default. 302, 307, 500, 503 are typically not cached. Return the wrong status code on a dynamic page and it may be unexpectedly cached at the edge — always verify your CDN's default caching rules per status code.

Frequently Asked Questions

What is the difference between 401 and 403?

401 Unauthorized (poorly named!) means "not authenticated" — the client must provide credentials to access this resource. 403 Forbidden means "not authorized" — the client is authenticated but lacks permission for this specific resource. Return 401 when no token exists; return 403 when the token is valid but the user doesn't have access rights.

When should I use 404 vs 403 for a resource a user can't access?

This is a security decision. 403 reveals the resource exists but is forbidden. 404 ("resource not found") hides its existence entirely. For sensitive resources (admin panels, other users' data), returning 404 instead of 403 is a security best practice — it prevents attackers from enumerating existing but private resource URLs.

What is the correct status code for a REST API validation error?

422 Unprocessable Entity is the most semantically correct for when the request syntax is valid HTTP but the content fails domain validation (e.g., "email is required", "age must be over 18"). However, 400 Bad Request is also widely used and broadly understood by API consumers. Both are acceptable; choose one consistently across your entire API.

What is the difference between 301, 302, and 307 redirects?

301 Permanent Redirect: browsers and Google permanently cache this redirect — use for URL changes you will never reverse (SEO passes link equity). 302 Found: originally temporary; browsers may cache. 307 Temporary Redirect: temporary redirect that preserves the HTTP method — a POST to /old stays a POST at /new (unlike 302, which browsers may convert to GET). For API redirects that must preserve method, always use 307 or 308.

What does a 429 status code mean?

429 Too Many Requests means the client has exceeded the API's rate limit. The server should (but is not required to) include a Retry-After header indicating how long to wait. Implement exponential backoff in your client when receiving 429 responses — don't retry immediately or you will make the rate limiting worse.

What status code should an API return when a database is down?

503 Service Unavailable is the correct code — the server is temporarily unable to handle the request due to an overloaded or unavailable dependency (like a database). Include a Retry-After header if you know when the service will recover. Do not return 500 Internal Server Error for expected outage scenarios — 503 signals a temporary condition while 500 signals an unexpected bug.

How This Tool Works

All HTTP status code data (RFC 9110 + registered IANA codes) is bundled as a static data object within the application — no API calls are required to look up codes. The search runs client-side using simple substring matching on code numbers, names, and descriptions. The "Next Actions" and "Common Causes" content is curated editorial content based on RFC specifications and common real-world API development patterns.

Technical Stack

Browser-native JavaScriptStatic data (RFC 9110 + IANA registry)Client-side searchNo external API calls

Related Tools

JWT Decoder

Decode and inspect JSON Web Tokens (JWT) without validation.

Cron Expression Generator

Build and decode cron schedule expressions visually — get human-readable descriptions and next run times.

User Agent Parser

Decode any User-Agent string — identify browser, engine, OS, device type, and bot classification.

SQL Formatter

Format and beautify SQL queries.

Unix Timestamp Converter

Convert Unix epoch timestamps to human-readable dates and vice versa — with timezone support.

JSON Path Tester

Test JSONPath expressions against your JSON.