HTTP Status Code Query
Quick reference for HTTP status codes with descriptions
1xx Information(4)
Client should continue sending the rest of the request.
Server understands and will switch to a different protocol.
Server has received the request and is processing it.
Returns some headers before the final response for preloading.
2xx Success(10)
Request succeeded. Response contains the requested data.
Request succeeded and a new resource was created. Common for POST.
Request accepted for processing, but not yet completed.
Request succeeded, but information may be from a third party.
Request succeeded, but no content in response. Common for DELETE.
Request succeeded, client should reset the document view.
Server delivered partial content. Used for resuming downloads.
Multiple status codes in response (WebDAV).
DAV bindings already listed in previous response (WebDAV).
Server completed GET request using instance manipulation.
3xx Redirect(8)
Multiple representations available, client should choose one.
Resource permanently moved to new URL. Use new URL.
Resource temporarily at another URL.
Use GET to retrieve resource from another URL.
Resource not modified. Use cached version.
Use specified proxy (deprecated).
Temporary redirect with same method and body.
Permanent redirect with same method.
4xx Client Error(29)
Server cannot understand request format.
Authentication required.
Reserved for future use. Common for paywalled content.
Server understood but refuses to authorize.
Resource does not exist. Most common status code.
Request method not supported.
Cannot return content matching Accept header.
Client must authenticate with proxy first.
Server timed out waiting for request.
Request conflicts with server state. Common for PUT.
Resource permanently removed.
Request must include Content-Length header.
Conditions in request headers not met.
Request body too large.
Request URL too long.
Request body format not supported.
Requested range invalid.
Expect header requirements not met.
RFC 2324 easter egg. Server refuses to brew coffee.
Request sent to wrong server.
Well-formed request but semantic errors.
Resource locked (WebDAV).
Request failed due to previous failure (WebDAV).
Server unwilling to process potentially replayed request.
Client should switch to TLS.
Request requires conditional headers.
Rate limit exceeded. Slow down.
Request headers too large.
Resource unavailable for legal reasons.
5xx Server Error(11)
Server encountered unexpected condition.
Server does not support required functionality.
Server received invalid response from upstream.
Server temporarily unable to handle request.
Server timed out waiting for upstream response.
HTTP version not supported.
Content negotiation configuration error.
Server cannot store resource (WebDAV).
Infinite loop detected (WebDAV).
Further extensions required.
Network authentication required.
What are HTTP Status Codes?
The HTTP Status Code tool explains the response codes a server returns to a browser, crawler, app, or API client after a request. A 2xx code usually means success, 3xx points to redirection, 4xx indicates a client-side problem, and 5xx signals a server-side failure, but the details matter. A 401 is not the same as a 403, a 404 is not the same as a 410, and a 301 has different SEO behavior from a 302. This reference helps developers, support teams, and site owners interpret codes quickly and decide what to check next. When used with others, inputs, assumptions, and the expected outcome should be clear so the result is not misread.
How to Use
Quick Reference
- Click any status code card to copy it
- Use the search box to quickly find specific codes
- Click category tags to filter by status type
- Hover over codes to see detailed descriptions
Debugging Notes
- Read the status family first: 2xx success, 3xx redirect, 4xx client-side issue, 5xx server-side issue.
- For API debugging, pair the status code with response body, headers, request method, and server logs; the code alone rarely explains the full problem.
Use Cases
Technical Principle
HTTP status codes are 3-digit integers returned on the response start-line, defined by the HTTP semantics specification. The current normative reference is RFC 9110 (HTTP Semantics, June 2022), which obsoletes the earlier RFC 7231 series, with extensions in RFC 9111 (Caching), RFC 9112 (HTTP/1.1), RFC 9113 (HTTP/2), and RFC 9114 (HTTP/3). The first digit defines the response class so unrecognised codes still have predictable handling: 1xx informational (interim, the final response follows), 2xx successful, 3xx redirection (further action by the user agent is required), 4xx client error (the request is malformed or cannot be fulfilled), and 5xx server error. Caches and intermediaries are required to treat unknown codes as the generic class code x00 (e.g. an unknown 4xx is handled like 400), which is what makes the status family meaningful even for proprietary or extension codes. Redirect codes carry method-preservation semantics that historically diverged from intent. RFC 9110 §15.4 makes the distinction explicit: 301 Moved Permanently and 302 Found may rewrite a POST to a GET (the de-facto behaviour all browsers settled on by the late 1990s, codified in RFC 7231); 307 Temporary Redirect and 308 Permanent Redirect require the user agent to repeat the same method and body. SEO tooling typically transfers PageRank-equivalent weight on 301 and 308 and treats 302 / 307 as preserving the original URL's signal. Conditional codes 304 Not Modified and 412 Precondition Failed depend on the request's If-None-Match / If-Modified-Since / ETag / Last-Modified headers, and 206 Partial Content responds to a Range header with a Content-Range header and a multipart/byteranges body when multiple ranges are requested. The 4xx and 5xx classes carry contract details in headers. 401 Unauthorized must include a WWW-Authenticate challenge listing accepted schemes (Bearer, Basic, Digest, Negotiate); without it the response is technically malformed. 405 Method Not Allowed must include an Allow header listing the supported methods. 429 Too Many Requests, 503 Service Unavailable, and 301/307/308 with Retry-After let the server signal a delay either in seconds (Retry-After: 120) or as an HTTP-date (Retry-After: Wed, 21 Oct 2025 07:28:00 GMT) per RFC 9110 §10.2.3. RFC 9110 deprecates 305 Use Proxy and 306 (reserved/unused), keeps 418 I'm a teapot as the documented RFC 2324 / RFC 7168 joke code, and reorganises 1xx so only 100 Continue and 101 Switching Protocols are required at the HTTP/1.1 layer; 102 Processing and 103 Early Hints (RFC 8297) are optional extensions surfaced mainly through CDN edge logic.
- Normative reference: RFC 9110 (HTTP Semantics, June 2022) obsoletes RFC 7230-7235; extensions live in RFC 9111 (Caching), 9112 (HTTP/1.1 wire format), 9113 (HTTP/2), 9114 (HTTP/3).
- Unknown codes degrade to the class code (x00): an unknown 4xx is cached and rendered like 400, an unknown 5xx like 500 - this is what makes the first digit a contract.
- Method preservation: 301/302 historically allow POST → GET rewrite (codified after early-1990s browser divergence); 307/308 require the same method and body to be replayed - use 308 for permanent API endpoint moves.
- 401 Unauthorized must carry WWW-Authenticate; 405 Method Not Allowed must carry Allow; missing these headers is a spec violation that breaks well-behaved HTTP clients.
- Retry-After (RFC 9110 §10.2.3) on 429/503/301/307/308: accepts either delta-seconds (Retry-After: 120) or HTTP-date (Retry-After: Wed, 21 Oct 2025 07:28:00 GMT) - clients should parse both forms.
- Conditional caching: 304 Not Modified responds to If-None-Match / If-Modified-Since matches with no body; 206 Partial Content responds to Range with Content-Range and either the partial body or a multipart/byteranges document.
- RFC 9110 deprecates 305 Use Proxy and 306 (reserved), preserves 418 I'm a teapot from RFC 2324 / RFC 7168 as a joke, and treats 102 Processing / 103 Early Hints (RFC 8297) as optional 1xx extensions that many proxies strip.
Examples
2xx Success - 200 OK and 204 No Content
200 OK GET /api/users -> response body returned
201 Created POST /api/posts -> new resource at Location header
204 No Content DELETE /api/posts/42 -> success, empty body
206 Partial Range request for video streaming or resumable downloads
RFC: RFC 7231 section 6.3 defines 2xx success status codes3xx Redirects - 301 vs 302 vs 304
301 Moved Permanently -> SEO-safe, browsers cache the new URL forever
302 Found -> temporary redirect, do not cache the target
304 Not Modified -> cached copy is still fresh (ETag/Last-Modified match)
307 Temporary Redirect -> like 302 but method must NOT change (POST stays POST)
308 Permanent Redirect -> like 301 but preserves the request method
RFC: RFC 7231 section 6.4 defines 3xx redirection codes
RFC: RFC 7232 section 4.1 defines 304 Not Modified semantics4xx Client errors - auth vs permission
400 Bad Request Malformed JSON, missing required field
401 Unauthorized Missing or invalid token - caller must authenticate
403 Forbidden Authenticated but not allowed to access this resource
404 Not Found Resource does not exist (or pretend it doesn't, for security)
409 Conflict Duplicate key, optimistic-lock version mismatch
429 Too Many Reqs Rate limit hit - see Retry-After header
RFC: RFC 7231 section 6.5 defines 4xx client error codes
RFC: RFC 6585 section 4 defines 429 Too Many Requests5xx Server errors - debugging an upstream
500 Internal Server Error Unhandled exception in app code - check logs
502 Bad Gateway Nginx/upstream got an invalid response from backend
503 Service Unavailable Maintenance, overloaded, or app booting up
504 Gateway Timeout Upstream did not respond within the proxy's timeout
RFC: RFC 7231 section 6.6 defines 5xx server error codes
Quick triage: 5xx = our fault, 4xx = caller's faultReal curl session showing several codes
$ curl -I https://example.com/old-page
HTTP/2 301
location: https://example.com/new-page
$ curl -I https://example.com/admin
HTTP/2 401
www-authenticate: Bearer realm="api"
$ curl -X POST https://example.com/api/posts -d '{}'
HTTP/2 422
content-type: application/json
Note: 422 Unprocessable Entity is a WebDAV extension (RFC 4918) used for validation errorsFAQ
What do the 1xx, 2xx, 3xx, 4xx, and 5xx classes mean?
1xx is informational (rare in practice). 2xx means the request succeeded. 3xx is a redirect - the client should follow a different URL. 4xx is a client-side problem (bad request, missing auth, missing resource). 5xx is a server-side problem (the request looked fine but the server failed to fulfil it). Always check the class first when reading a log line.
What is the difference between 301 and 302?
301 Moved Permanently tells clients and search engines that the resource has permanently moved - browsers cache the redirect aggressively and SEO link equity transfers to the new URL. 302 Found is a temporary redirect; clients are not supposed to cache it long-term. Use 308 for permanent redirects when you must preserve the request method, and 307 for temporary redirects under the same constraint.
When should I return 401 vs. 403?
401 Unauthorized means the client did not authenticate, or the credentials it sent are invalid - the response should include a WWW-Authenticate header. 403 Forbidden means the server understood who the client is and is refusing to serve this resource regardless. Logging-in fixes 401; logging in does not fix 403.
Should I use 404 or 410 for resources that no longer exist?
404 Not Found means 'I cannot find this; it may exist somewhere or come back later.' 410 Gone means 'this resource was here, it is intentionally removed, do not look for it again.' Search engines drop 410 URLs from the index faster than 404, so 410 is the right choice for retired pages you do not want re-crawled.
How should I read a status code when debugging an API?
Read the class first (4xx vs 5xx tells you which side to look at), then the specific code, then the response body. The body usually carries the actual error message and an internal error code; the HTTP status is just the category. Always inspect headers like Retry-After, WWW-Authenticate, and Location alongside the status.
Do non-2xx codes hurt SEO?
Some do, some do not. Long-lived 5xx responses signal an unreliable site and search engines will eventually reduce crawl frequency. 301/308 redirects pass link equity; 302/307 do not. 410 removes pages from the index; 404s hang around longer. 200 with a soft-404 body (a real 'not found' page returning 200) is worse for SEO than a real 404 because it fills the index with empty pages.
What are 418, 451, and other unusual codes for?
418 'I'm a teapot' is the famous April Fools' code from RFC 2324 - real services should never return it in production. 451 Unavailable For Legal Reasons indicates the resource is blocked because of a legal demand (named after Bradbury's Fahrenheit 451). 429 Too Many Requests signals rate-limiting and should be paired with a Retry-After header. 503 Service Unavailable is the right code for planned maintenance.