HTTP Status Code Reference
Web ToolsComplete reference for every HTTP status code with meaning, usage guidelines, and examples for REST API design.. Free, private — all processing in your browser.
The server received the request headers and the client should proceed to send the body.
The server is switching protocols as requested by the client (e.g. to WebSocket).
Used to return some response headers before the final HTTP message, often to preload resources.
The request succeeded. The meaning depends on the HTTP method used.
The request succeeded and a new resource was created, usually after a POST or PUT.
The request was accepted for processing, but processing has not completed.
The request succeeded but there is no content to send in the response body.
The server is delivering only part of the resource due to a Range header sent by the client.
The resource has permanently moved to a new URL. Search engines pass link equity to the new URL.
The resource temporarily resides at a different URL. The original URL should keep being used.
The cached version is still valid; the client can reuse it. Saves bandwidth.
Like 302, but the request method must not change when redirecting.
Like 301, but the request method and body must not change when redirecting.
The server cannot process the request due to a client error (malformed syntax, invalid framing).
Authentication is required and has failed or not been provided.
The server understood the request but refuses to authorize it. Authentication won't help.
The server cannot find the requested resource. The most recognized status code.
The request method is known but not supported by the target resource.
The server timed out waiting for the request.
The request conflicts with the current state of the server (e.g. edit conflicts).
The resource is permanently gone with no forwarding address. Stronger than 404.
An April Fools' joke from 1998. The server refuses to brew coffee because it is a teapot.
The request was well-formed but contains semantic errors (common in REST APIs for validation).
The user has sent too many requests in a given amount of time (rate limiting).
A generic error message when the server encounters an unexpected condition.
The server does not support the functionality required to fulfill the request.
The server, acting as a gateway, received an invalid response from the upstream server.
The server is not ready to handle the request — often overloaded or down for maintenance.
The server, acting as a gateway, did not get a response in time from the upstream server.
A searchable reference for HTTP status codes — type a number (404), a name ("not found"), or a symptom ("timeout") and get the code, what it actually means, and when you'll run into it. Filter by class (1xx–5xx) to browse a family at a time.
It's meant to settle the codes that get mixed up in real work: is it 401 or 403? Should a redirect be 301 or 302? Why did the API return 200 with an error inside it? Each entry is written in plain terms rather than the terse spec wording.
Features at a glance
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.
Technical details
The first digit is the whole story — it tells you the *class* of response before you know the exact code:
- 1xx Informational — rare in app code; the request was received, keep going (e.g. 101 upgrading to WebSocket).
- 2xx Success — it worked. 200 OK is the default; 201 Created after a POST; 204 No Content when there's nothing to return (common after DELETE).
- 3xx Redirection — go somewhere else. 301/308 permanent, 302/307 temporary.
- 4xx Client Error — *you* sent something wrong: bad input, missing auth, no permission, wrong method.
- 5xx Server Error — the server broke while handling a valid request.
The distinctions worth memorizing:
- 401 vs 403. 401 means "unauthenticated" — you didn't prove who you are (despite the name "Unauthorized"). 403 means "authenticated but not allowed." Sending 401 when you mean 403 is a classic mislabel.
- 301 vs 302. 301 is permanent and passes SEO link equity to the new URL; 302 is temporary and keeps the old URL's ranking. Using 302 for a permanent move quietly costs you SEO.
- 307/308 vs 302/301. The newer pair guarantees the HTTP method won't change on redirect (a POST stays a POST), which the older codes didn't promise.
- 422 vs 400. 400 is malformed syntax; 422 is well-formed but semantically invalid (validation failed) — many APIs use 422 for form errors.
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 in practice
Successful POST
Creating a resource, returning 201 with Location header.
POST /api/users with new user JSON
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.
POST /api/users with email missing
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.
GET /api/private-resource without token
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.
GET /api/endpoint (110th request this minute, limit 100)
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.
GET /old-page
HTTP/1.1 301 Moved Permanently Location: /new-page (search engines update indexed links)
Pitfalls and fixes
⚠Using 401 when you mean 403
401 means the request lacks valid authentication (you're not logged in). 403 means you're authenticated but not permitted. Sending 401 to a logged-in user who simply lacks access is wrong and confuses clients.
⚠Using 302 for a permanent redirect
302 is temporary and keeps the old URL's SEO value. For a page that moved for good, use 301 (or 308) so search engines transfer ranking to the new URL.
⚠Returning 200 with an error in the body
Clients, monitoring, and caches trust the status line. Wrapping an error in a 200 breaks all of them. Return the matching 4xx/5xx and put details in the body.
⚠404 vs 410 for removed content
404 says 'not found' (maybe temporary, maybe a typo). 410 Gone says 'this existed and is permanently removed' — a stronger signal that tells search engines to drop it faster.
⚠Treating 429 as a server error
429 Too Many Requests is rate limiting — it's on the client to slow down and honor the Retry-After header, not a server fault to alert on.
HTTP Status Code Reference — comparisons and alternatives
301 vs 302 vs 307 vs 308. Permanent (301/308) tells clients and search engines to update to the new URL and passes ranking; temporary (302/307) says "just this once, keep using the original." The 307/308 pair additionally forbids changing the method. Rule of thumb: permanent move of a page → 301; temporary maintenance redirect → 302; API redirect that must preserve a POST → 307/308.
401 vs 403. Not signed in / bad credentials → 401 (the client can fix it by authenticating). Signed in but lacking permission → 403 (authenticating again won't help).
200-with-an-error-body (the anti-pattern). Some APIs return 200 OK with {"error": "..."} inside. That breaks every client that trusts status codes, monitoring that counts 5xx, and caching. Return the code that matches reality — 400/401/403/404/409/422/500 — and put detail in the body.
Questions and answers
▶What's the difference between 401 and 403?
401 Unauthorized actually means unauthenticated — you haven't proven who you are, and providing valid credentials would fix it. 403 Forbidden means you're authenticated but not allowed; re-authenticating won't help.
▶Should I use 301 or 302 for a redirect?
301 for a permanent move — it passes SEO link equity to the new URL. 302 for a temporary one — the original URL keeps its ranking. Using 302 for a permanent change loses SEO value.
▶What does 429 mean?
Too Many Requests — you've hit a rate limit. Back off and retry after the delay in the Retry-After header. It's a signal to the client, not a server error.
▶Why is returning 200 with an error bad?
Because clients, monitoring, and caches rely on the status code to know success from failure. A 200 that actually failed silently breaks retries, alerts, and caching. Use the real status code and describe the error in the body.
▶What's the difference between 404 and 410?
404 Not Found is neutral — maybe it never existed, maybe a typo. 410 Gone explicitly says the resource existed and is permanently removed, which prompts search engines to de-index it sooner.
▶When do I use 307 or 308 instead of 302 or 301?
When the redirect must preserve the HTTP method and body. 301/302 historically allowed clients to switch a POST to a GET on redirect; 308 (permanent) and 307 (temporary) guarantee the method stays the same.
Further reading
- RFC 9110 HTTP Semantics — Current authoritative specification for HTTP status codes and semantics.
- IANA HTTP Status Code Registry — Official registry of all assigned HTTP status codes.
- RFC 7807 Problem Details — Standard for structured error responses in JSON APIs.
- MDN HTTP Status — Comprehensive MDN reference for HTTP status codes with examples.
- Google JSON Style Guide — Errors — Google’s API error response format, influential in API design.
Related tools
All Web ToolsAPI 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
Explore more tools
200+ free tools that run in your browser.
Browse all tools →