A complete HTTP status code reference: meaning, causes, RFC and how to handle, all in your browser.
HTTP status codes communicate, in three digits, the result of every request between client and server, and they are defined mainly by RFC 9110. The first digit sets the family: 1xx (informational, a provisional response), 2xx (success), 3xx (redirection), 4xx (client error, such as a malformed or unauthorized request) and 5xx (server error). This reference gathers codes from all five families with their meaning, the specification (RFC) that defines them, whether the response is cacheable by default, whether it usually carries a body, plus common causes and how to handle the most frequent errors. It is a fully offline lookup: you type the number (like 404) or a term (like timeout or redirect) and see the explanation instantly, without the tool making any network request. It is handy for debugging API responses, reading server logs, choosing the right code when building an endpoint and auditing SEO redirects.
Every status code has three digits, and the first one summarizes the nature of the response before you even read the exact number. Learning to read the class is the fastest shortcut to a diagnosis: a 4xx points the finger at the client (the request), while a 5xx points at the server (the infrastructure). That completely changes who needs to act, the developer who made the call, or whoever operates the backend.
The ranges follow RFC 9110: 1xx is a provisional response (the request arrived and processing continues), 2xx confirms success, 3xx signals that a further action is needed (usually following a redirect), 4xx flags a client-side error and 5xx a server-side error.
Example 1, 401 versus 403. A 401 (Unauthorized) says "I don't know who you are": valid credentials are missing, and sending a correct token fixes it. A 403 (Forbidden) says "I know who you are, but you can't": authentication is fine, permission simply isn't there, and re-authenticating changes nothing. Confusing the two sends users to a login screen that will never unlock the resource.
Example 2, redirects 301, 302 and 307/308. A 301 (Moved Permanently) is definitive and consolidates SEO signals on the new address; a 302 is temporary. A critical detail: 301 and 302 may cause the browser to switch a POST to GET when redirecting, whereas 307 and 308 preserve the original method and body, which is why APIs that redirect POST requests should use 307/308 so the submitted data is not lost.
The reference helps when debugging an API that returns an unexpected code, when reading access logs (where the status appears on every line), when deciding which code to return from an endpoint you are building and when auditing redirects for SEO. For every curated code you can see the family, the source RFC, whether it is cacheable by default and whether it usually carries a body.
The important limit is by design: this is a purely local lookup. The tool does not fetch the URL you type, makes no network requests and does not access any site, it only explains what the codes mean. That keeps the lookup fast, private and immune to firewall or CORS blocks.
Paste the code into your HTML and the tool shows up on your page, without J-Kit's navigation and ads. It still runs in the browser of whoever visits your site.
<iframe
src="https://jkit.tools/embed/en-US/http-status-codes"
width="100%"
height="600"
style="border:0"
loading="lazy"
title="HTTP Status Codes"
></iframe>These references help contextualize formulas, standards, APIs and limitations used on this page. They do not replace professional validation when a result has legal, financial, medical or operational impact.
401 (Unauthorized) means valid authentication is missing, you must identify yourself, and sending correct credentials fixes it. 403 (Forbidden) means you are authenticated but not allowed to access the resource; re-authenticating will not help. In practice, 401 asks for a login and 403 signals a lack of authorization even when already logged in.
The client should continue sending the request body (after Expect: 100-continue).
The server agrees to switch protocols (e.g. upgrade to WebSocket).
Lets the client preload resources (Link headers) before the final response.
Standard success. The body depends on the method (GET returns the resource).
A resource was created; usually accompanied by a Location header.
Request accepted for async processing; not yet completed.
Success, but an intermediate proxy modified the content of the origin server’s original response.
Success with no response body (common for DELETE and PUT).
Success with no body; tells the user agent to reset the form or view that triggered the request.
Partial response to a request with a Range header (downloads, video).
The resource has more than one representation; the client should pick one. Rarely used in practice, with no standardized format for automatic selection.
The resource permanently moved; update links and bookmarks.
Temporary redirect; the method may change to GET in practice.
Look at another resource using GET (Post/Redirect/Get pattern).
The cached resource is still valid (ETag/If-Modified-Since); use the cache. The response itself carries no content, so RFC 9110 does not list it as cacheable by default the way it does 200.
Temporary redirect that preserves the method and body.
Permanent redirect that preserves the method and body.
The server could not understand the request due to malformed syntax or invalid data.
Valid authentication is missing. Despite the name, it is about authentication, not permission.
Reserved for future use by RFC 9110. Some payment APIs reuse it non-standardly to signal a pending charge.
Authenticated but not allowed to access the resource. Re-authenticating will not help.
The resource does not exist at this URL (or the server hides its existence).
The HTTP method is not allowed on this resource (see the Allow header).
No representation matches the client’s Accept header.
Like 401, but the authentication required is for a proxy, not the origin server.
The client took too long to send the complete request.
Conflict with the current state of the resource (e.g. concurrent edit).
The resource existed and was permanently removed.
The server refuses the request without a defined Content-Length.
A precondition sent by the client (If-Match, If-Unmodified-Since, etc.) evaluated to false on the server.
The request body is larger than the server is willing to accept.
The URL is too long (usually a huge query string on a GET).
The request body Content-Type is not supported by the endpoint.
The range requested in the Range header could not be satisfied (common in resumed downloads and video streaming).
A server along the path could not meet the expectation in the Expect header (e.g. 100-continue).
A 1998 joke (RFC 2324/7168, the HTCPCP protocol). RFC 9110 now formally lists the code as reserved (“Unused”) because of how widely it has been deployed as a joke, so it cannot be given serious semantics; it is nonetheless still widely implemented as an easter egg across frameworks and tools.
The request reached a server that cannot give an authoritative response for that origin, common when an HTTP/2 connection is reused across different domains.
Syntax is fine, but the semantics are invalid (business validation failed).
The resource is locked (WebDAV extension), common in file storage and collaborative-editing services.
The request failed because another request it depended on failed first (WebDAV extension).
The server refuses to process data sent too early (0-RTT anti-replay).
The client must switch to a different protocol (e.g. newer TLS).
The server requires a precondition (e.g. If-Match) to avoid lost updates.
Rate limit reached. Check the Retry-After header before retrying.
The headers (or a single cookie) are too large.
Content blocked for legal reasons (censorship, DMCA, GDPR).
A generic, unexpected server error. Check the backend logs.
The server does not support the functionality required (e.g. the method).
A proxy/gateway got an invalid response from the upstream server.
The server is temporarily unavailable (overload or maintenance).
A proxy/gateway did not get a response from upstream in time.
The HTTP version used in the request is not supported.
A content-negotiation configuration error: the chosen variant also negotiates, creating a loop the server has to break.
The server lacks storage to complete the request (WebDAV).
The server detected an infinite loop while processing a WebDAV request with unlimited depth (Depth: infinity).
You must authenticate to the network (Wi-Fi captive portals).
This is an offline reference: nothing is sent over the network. The tool does not access any site or make requests, it only explains the codes.