What is HTTP Status Codes Reference?
A HTTP Status Codes Reference computes http status codes reference from the inputs you provide. It applies the standard formula to the values you enter and returns the result instantly, without sending any data to a server. 1xx-5xx with descriptions, common causes, when to use each.
HTTP Status Codes Reference
All HTTP status codes with description, common causes, and when to use each. Searchable.
TLDR
Searchable reference of every HTTP status code 100-599, organized by class (Informational, Success, Redirection, Client Error, Server Error). Each entry includes the official name, RFC meaning, and a short note on when to use it.
How to use this tool
- Enter your inputs. Each field is labeled with what it expects.
- Read the result instantly. Numbers update as you type or change inputs.
- Adjust to test sensitivity. Change one input at a time to see what moves the result most.
- Cross-check the formula in the section below if you want to verify the math.
- Copy or screenshot the result for later. The site does not save anything; close the tab and inputs are gone.
About this tool + how it works
This tool runs 100% in your browser - the libraries load from a public CDN and the math runs on your device. Nothing is uploaded to a server. The underlying logic is:
RFC 9110 + IANA registry + common framework conventions
You can verify by opening the browser developer tools and watching the Network tab; you'll see no requests fired during normal use beyond the initial page and library load.
Real-world scenarios where this tool helps
Quick local use
Avoid the cloud round-trip when you just need a fast http status codes reference.
Bookmark for later
Stays handy as a tab; no signup, no cookies.
Privacy-sensitive content
Sensitive strings / API keys / personal data stay in your browser.
Mobile and slow connections
Local processing beats waiting on an API response.
What this tool does
- Runs the http status codes reference 100% in your browser - no upload, no API, no signup.
- Live error messages when input is malformed.
- One-click Copy and Clear buttons.
- Works on phones, tablets, and desktops; loads in under a second.
- Free forever; no premium tier.
What it does NOT do
- Does not store, log, or send your input anywhere.
- Does not require an account, an API key, or a paid plan.
- Does not fix malformed input - garbage in produces an error message.
- Does not need an internet connection after first page load (libraries cache).
HTTP status code classes explained
Every HTTP response carries a three-digit status code, and the first digit places it in one of five classes. Reading that first digit tells you immediately whether a request succeeded, was redirected, failed because of the client, or failed because of the server, before you read any further. The classes were defined in the original HTTP specification and are now maintained by the IETF in RFC 9110.
| Class | Meaning | Examples |
|---|---|---|
| 1xx Informational | Request received, processing continues | 100, 101, 103 |
| 2xx Success | Request succeeded | 200, 201, 204 |
| 3xx Redirection | Further action needed to complete | 301, 302, 304 |
| 4xx Client error | The request was wrong | 400, 401, 404, 429 |
| 5xx Server error | The server failed to fulfil a valid request | 500, 502, 503, 504 |
The most important distinction in practice is 4xx versus 5xx. A 4xx code means the problem is on the requester's side: a wrong URL, a missing token, an unsupported method, or a malformed body. A 5xx code means the server received a valid request but could not produce a correct response, often because of an unhandled exception, a failed upstream service, or an overloaded backend. Knowing which side owns the failure tells you whether to fix your request or investigate the server.
The codes you will meet most often
A handful of codes account for the vast majority of real-world traffic. These are the ones worth memorising.
- 200 OK: the default success response. The request worked and the body holds the result.
- 201 Created: a POST created a new resource. APIs return this after a successful create, often with the new resource's location.
- 301 vs 302: 301 Moved Permanently tells browsers and search engines the URL changed for good and to update bookmarks and links; 302 Found is a temporary redirect that leaves the original URL authoritative.
- 304 Not Modified: the cached copy is still valid, so the server sends no body. This is how conditional caching saves bandwidth.
- 401 vs 403: 401 Unauthorized actually means unauthenticated (you have not proven who you are); 403 Forbidden means you are authenticated but lack permission for this resource.
- 404 Not Found: the resource does not exist at that URL. The single most recognised code on the web.
- 429 Too Many Requests: you hit a rate limit. Back off and retry after the interval the server suggests.
- 500 vs 503: 500 Internal Server Error is a generic, unhandled server failure; 503 Service Unavailable means the server is temporarily down or overloaded and may recover shortly.
Worked example: reading a redirect chain
Suppose you request an old article URL over plain HTTP and trace the responses your browser receives.
- 301 Moved Permanently: the HTTP URL redirects to the HTTPS version. The browser caches this and will skip straight to HTTPS next time.
- 302 Found: the HTTPS URL temporarily points the old article slug to a new path, perhaps during a content migration.
- 200 OK: the new path returns the article body. The chain ends here.
Result
Three responses, two of them redirects, produced one page. The 301 is permanent (update your links), the 302 is temporary (the old slug may come back), and the final 200 is the content. Search engines pass ranking signals through 301s but treat 302s as temporary, which is why using the right redirect code matters for SEO.
Common mistakes and pitfalls
- Treating 401 as "no permission". 401 means not authenticated; the fix is to log in or send a valid token. Use 403 when the user is known but not allowed.
- Using 200 for errors. Returning 200 with an error message in the body breaks clients, caches, and monitoring. Use the correct 4xx or 5xx so tooling can react.
- Confusing 301 and 302. A permanent move marked 302 stops search engines from transferring link equity; a temporary move marked 301 can be cached forever by browsers.
- Ignoring 429 retry headers. Hammering an endpoint after a 429 makes the rate limit worse. Respect the Retry-After header.
- Blaming the client for a 5xx. A 5xx is the server admitting fault on a valid request; check server logs rather than the request when you see one.
Related tools
Frequently asked questions
What is the difference between a 401 and a 403 status code?
A 401 Unauthorized means you are not authenticated: the server does not know who you are, and the fix is to log in or send a valid credential. A 403 Forbidden means you are authenticated but lack permission for that specific resource. Despite its name, 401 is about identity, while 403 is about authorization.
What does a 404 status code mean?
404 Not Found means the server could not find any resource at the requested URL. The request itself was valid, but the target does not exist, perhaps because of a typo, a deleted page, or a broken link. If the resource was removed permanently and you want to say so explicitly, use 410 Gone instead.
When should I use a 301 versus a 302 redirect?
Use 301 Moved Permanently when a URL has changed for good: browsers cache it and search engines transfer ranking signals to the new location. Use 302 Found (or 307) for a temporary move, where the original URL should stay authoritative. Picking the wrong one can either strand link equity or cause a permanent redirect to be cached forever.
What is the difference between a 4xx and a 5xx error?
A 4xx code is a client error: the request was malformed, unauthorized, or pointed at something that does not exist, so the fix is on the requester's side. A 5xx code is a server error: the request was valid but the server failed to handle it, usually due to a bug, a failed dependency, or overload. The first digit tells you which side to investigate.
What does a 429 Too Many Requests code mean?
429 means you have sent too many requests in a given window and have hit a rate limit. The server usually includes a Retry-After header telling you how long to wait. The correct response is to pause and back off, ideally with exponential backoff, rather than retrying immediately, which only prolongs the limit.
