Continue
The server got the request headers and the client may send the body. Used with "Expect: 100-continue" before large uploads.
RFC 9110HTTP Status Codes
Search by number or name, or filter by class. Each code links to its specification.
1xx Informational
The request was received and the process continues. Rarely seen in application code.
Switching Protocols
The server agrees to switch protocols as the client asked, for example from HTTP/1.1 to WebSocket.
RFC 9110Processing
WebDAV: the server accepted the request and is still working on it, so the client should not time out.
RFC 2518Early Hints
Sends Link headers early so the browser can preload CSS or fonts while the server prepares the final response.
RFC 82972xx Success
The request was received, understood and accepted.
OK
The request succeeded. The body contains the requested resource or the result of the action.
RFC 9110Created
A new resource was created, typically after a POST. The Location header should point to it.
RFC 9110Accepted
The request was accepted for processing but is not finished yet, for example a queued background job.
RFC 9110Non-Authoritative Information
The response is OK but was modified by a transforming proxy, so it is not exactly what the origin sent.
RFC 9110No Content
Success with no body to return. Common for DELETE or for saving a form without reloading the page.
RFC 9110Partial Content
Only part of the resource is returned, as asked by a Range header. Used for resumable downloads and video seeking.
RFC 9110IM Used
The server applied delta encoding (instance manipulations) to the response. Very rarely used.
RFC 32293xx Redirection
Further action, usually following another URL, is needed to complete the request.
Multiple Choices
Several representations exist (for example languages or formats) and the client should choose one.
RFC 9110Moved Permanently
The resource has a new permanent URL, given in Location. Search engines transfer ranking to the new URL.
RFC 9110Found
The resource is temporarily at another URL. Clients keep using the original URL; browsers may turn a POST into a GET.
RFC 9110See Other
The result can be found at another URL with GET. Used after a form POST to avoid resubmission (Post/Redirect/Get).
RFC 9110Not Modified
The cached copy is still valid (If-None-Match or If-Modified-Since matched), so no body is sent.
RFC 9110Temporary Redirect
Temporary redirect that keeps the method and body, so a POST stays a POST.
RFC 9110Permanent Redirect
Permanent redirect that keeps the method and body. The strict version of 301.
RFC 91104xx Client error
The request is wrong: bad syntax, missing authentication, no permission or a resource that does not exist.
Bad Request
The server cannot process the request because it is malformed: invalid syntax, bad JSON or wrong parameters.
RFC 9110Unauthorized
Authentication is missing or invalid. The response includes WWW-Authenticate to say how to log in.
RFC 9110Payment Required
Reserved for future digital payment systems; some APIs use it when a subscription or quota must be paid.
RFC 9110Forbidden
The server knows who you are but refuses the action: you lack permission. Logging in again will not help.
RFC 9110Method Not Allowed
The HTTP method is not supported for this URL, for example POST on a read-only resource. Allow lists valid methods.
RFC 9110Not Acceptable
The server cannot produce a response matching the Accept headers (type, language or encoding).
RFC 9110Proxy Authentication Required
Like 401, but the client must authenticate with the proxy first.
RFC 9110Request Timeout
The server waited too long for the client to finish sending the request and closed the connection.
RFC 9110Conflict
The request conflicts with the current state, such as an edit conflict or a duplicate unique key.
RFC 9110Gone
The resource was deleted on purpose and will not come back. Search engines drop it faster than a 404.
RFC 9110Precondition Failed
A conditional header such as If-Match did not match, often used to prevent overwriting someone else's changes.
RFC 9110Content Too Large
The request body is larger than the server allows (formerly "Payload Too Large").
RFC 9110URI Too Long
The URL is longer than the server will accept, often because too much data was put in a GET query string.
RFC 9110Unsupported Media Type
The body format (Content-Type) is not supported, for example XML sent to a JSON-only API.
RFC 9110I'm a teapot
An April Fools' joke from the Hyper Text Coffee Pot Control Protocol: a teapot cannot brew coffee. Some sites use it as an easter egg.
RFC 2324Misdirected Request
The request reached a server that cannot answer for this host, for example when a reused HTTP/2 connection targets the wrong origin.
RFC 9110Unprocessable Content
The syntax is correct but the content is invalid, for example failed validation rules (formerly "Unprocessable Entity").
RFC 9110Failed Dependency
WebDAV: the request failed because it depended on another request that failed.
RFC 4918Too Early
The server will not process a request that might be replayed, such as TLS 1.3 early data.
RFC 8470Precondition Required
The server requires conditional requests (If-Match) to avoid lost updates.
RFC 6585Too Many Requests
The client sent too many requests in a given time (rate limiting). Retry-After says when to try again.
RFC 6585Request Header Fields Too Large
The headers are too large in total or one header is too large, often because of oversized cookies.
RFC 6585Unavailable For Legal Reasons
The resource is blocked for legal reasons, such as censorship or a court order. The number refers to "Fahrenheit 451".
RFC 77255xx Server error
The request looked valid but the server failed to handle it.
Internal Server Error
A generic error: something unexpected went wrong on the server. Check the server logs.
RFC 9110Not Implemented
The server does not support the feature or method needed to fulfil the request.
RFC 9110Bad Gateway
A gateway or proxy got an invalid response from the upstream server, for example when the app behind Nginx crashed.
RFC 9110Service Unavailable
The server is temporarily unable to handle requests because of overload or maintenance. Retry-After may say when to come back.
RFC 9110Variant Also Negotiates
Content negotiation is misconfigured: the chosen variant itself tries to negotiate.
RFC 2295Insufficient Storage
WebDAV: the server cannot store the data needed to complete the request.
RFC 4918Not Extended
Further extensions to the request are required. Obsolete and practically unused.
RFC 2774Network Authentication Required
The client must log in to the network first, typically a hotel or airport Wi-Fi captive portal.
RFC 6585What are HTTP status codes?
Every HTTP response starts with a three-digit status code that tells the client how the request went. The first digit sets the class: 1xx informational, 2xx success, 3xx redirection, 4xx client errors and 5xx server errors. Browsers, search engines, caches, API clients and monitoring tools all act on these codes, so choosing the right one matters: a 301 passes SEO value to a new URL while a 302 does not, a 503 tells crawlers to come back later, and a 429 tells API clients to slow down. The codes are defined mainly in RFC 9110 (HTTP Semantics), with a few in separate RFCs.
Features
- • All 61 IANA-registered status codes, from 100 to 511
- • Plain-language explanation of what each code means and when to use it
- • Instant search by number, name or keyword, plus class filters
- • Direct links to the RFC section that defines each code
- • Color-coded by class and linkable with #code anchors
Fast and offline-friendly
The whole reference is rendered into the page, so search runs instantly in your browser with no requests to a server.
Searchable reference, no tracking.
How to use the HTTP Status Codes
- 1
Type a number such as 404, a name such as "gateway", or a word such as "redirect" in the search box. Results update as you type.
- 2
Use the class chips (1xx to 5xx) to narrow the list, for example to review all client errors at once.
- 3
Read the explanation under each code to see what it means, when a server should send it and how clients react.
- 4
Follow the RFC link for the exact specification, or share a direct link to a code with an anchor such as #429.
Practical examples
Designing a REST API
Return 201 Created with a Location header after a POST, 204 No Content after a DELETE, 400 for malformed JSON, 422 for validation errors and 409 when the request conflicts with the current state.
Moving pages for SEO
Use 301 or 308 for permanent moves so search engines transfer rankings, and 302 or 307 for temporary redirects such as A/B tests. 308 and 307 also keep POST as POST.
Authentication errors
Send 401 when the user is not logged in or the token is invalid, and 403 when the user is known but not allowed. Many APIs return 404 instead of 403 to hide that a resource exists.
Maintenance and overload
Return 503 with a Retry-After header during maintenance so crawlers keep your rankings, and 429 with Retry-After when a client exceeds its rate limit.
Frequently asked questions
What is the difference between 401 and 403?+
401 Unauthorized means "who are you?": authentication is missing or failed. 403 Forbidden means "I know who you are, but you may not do this". Logging in again fixes a 401, not a 403.
301 or 302 for redirects?+
Use 301 (or 308) when the old URL is gone for good, and 302 (or 307) when it will come back. Using 302 for a permanent move can delay search engines from indexing the new URL.
What is the difference between 502, 503 and 504?+
502 Bad Gateway: a proxy got an invalid answer from the upstream server. 503 Service Unavailable: the server is overloaded or in maintenance. 504 Gateway Timeout: the upstream did not answer in time.
Should errors return 200 with an error message?+
No. Clients, caches and monitoring rely on the status code. Returning 200 for failures hides errors from tools and can get error pages indexed as "soft 404s".