Every developer keeps a mental shortlist of HTTP status codes. Mine used to be 200, 404, and 500, and for a long time that was enough to fake competence. Then I spent a week building a payment integration where the API returned 402 for a declined card, 409 when I retried a charge that had already gone through, and 429 when my tests hammered it too fast. Suddenly the difference between codes was the difference between a working feature and a support ticket. I build a lot of web tooling for toolz.dev, and a searchable status-code reference is one of those things I reach for constantly, so I built one into the site and wrote this guide to go with it.
TL;DR: An HTTP status code is a three-digit number a server sends back to describe the result of a request. The first digit sets the class: 1xx informational, 2xx success, 3xx redirection, 4xx client error, 5xx server error. Look any of them up instantly with the HTTP Status Codes tool, which lets you search by number, name, or keyword and cites the RFC that defines each one.
This guide walks through what status codes are, what each class means, the specific codes worth memorising, and the ones people most often get wrong. It is aimed at front-end developers debugging API calls, back-end developers deciding what to return, and anyone doing technical SEO who needs redirects to behave.
What is an HTTP status code?
Every time your browser or an app requests something over the web, the server answers with a response. The first line of that response contains a status code: a three-digit number, paired with a short reason phrase like "OK" or "Not Found". The code is the machine-readable summary of what happened, and the reason phrase is the human-friendly label. Clients act on the number; the phrase is for people reading logs.
Status codes are defined by the Internet Engineering Task Force, primarily in RFC 9110, which consolidated the older HTTP specifications in 2022. A central registry maintained by IANA lists every officially recognised code. That standardisation is what lets a browser written by one company talk to a server written by another and agree on what a 404 means. The HTTP Status Codes tool mirrors that registry, listing every standard code with its meaning and the RFC that defines it.
The key mental model is that the first digit tells you the category, and the category tells you who is responsible. A 4xx code means the client sent something wrong. A 5xx code means the server failed on a request that was fine. That single distinction resolves most debugging arguments about whose bug it is.
What do the five status code classes mean?
There are exactly five classes, grouped by the leading digit. Understanding the class is more valuable than memorising individual codes, because it tells you where to look.
The 1xx class is informational. These codes signal that the server received the request and processing continues. They are rare in everyday work. The best known is 100 Continue, and the most useful modern one is 103 Early Hints, which lets a server tell the browser to start preloading resources before the full response is ready.
The 2xx class means success. The request was received, understood, and accepted. 200 OK is the everyday success code, 201 Created confirms a new resource was made, and 204 No Content says "done, nothing to send back", which is common for delete operations.
The 3xx class is redirection. The resource lives somewhere else, or has not changed since the client last saw it. This class is where SEO lives, because 301 and 302 tell search engines whether a move is permanent. 304 Not Modified is a caching workhorse that saves enormous bandwidth.
The 4xx class is a client error. The request was malformed, unauthorised, or pointed at something that does not exist. 400, 401, 403, 404, and 429 all live here. When you see a 4xx, check what your code sent before you blame the server.
The 5xx class is a server error. The request was valid but the server could not fulfil it. 500, 502, 503, and 504 are the ones you will meet in production incidents, usually pointing at a crash, an overloaded service, or a broken upstream dependency.
Which HTTP status codes should every developer know?
You do not need all sixty-plus codes in your head. You need maybe fifteen, and the rest you look up. Here is the working set I think earns a permanent place in memory, with the situations that trigger them.
| Code | Meaning | When you see it |
|---|---|---|
| 200 | OK | A normal successful request |
| 201 | Created | A POST or PUT made a new resource |
| 204 | No Content | Success with an empty body, common after DELETE |
| 301 | Moved Permanently | A URL moved for good; SEO ranking transfers |
| 302 | Found | A temporary redirect; keep using the old URL |
| 304 | Not Modified | Cached copy is still valid; no body sent |
| 400 | Bad Request | Malformed syntax or invalid request framing |
| 401 | Unauthorized | Authentication missing or failed |
| 403 | Forbidden | Authenticated but not allowed |
| 404 | Not Found | The resource does not exist |
| 409 | Conflict | The request clashes with current state |
| 422 | Unprocessable Content | Valid syntax, failed validation rules |
| 429 | Too Many Requests | Rate limited; back off and retry |
| 500 | Internal Server Error | Unexpected server failure |
| 503 | Service Unavailable | Server overloaded or in maintenance |
The rest of the registry, from 226 IM Used to 451 Unavailable For Legal Reasons, is worth recognising but not memorising. That is exactly what a lookup tool is for.
What is the difference between 401 and 403?
This pair trips up almost everyone, so it deserves its own section. Both mean access was denied, but for different reasons, and the difference changes how your app should respond.
A 401 Unauthorized means the request lacks valid authentication. The server does not know who you are. Either you sent no credentials, or the ones you sent were wrong or expired. The correct response from your side is to log in or refresh the token. By spec, a 401 response should include a WWW-Authenticate header telling the client how to authenticate.
A 403 Forbidden means the server knows exactly who you are and is refusing anyway. You are authenticated but not authorised for this particular resource. Logging in again will not help, because the problem is permissions, not identity. A regular user hitting an admin-only endpoint should get a 403.
The quick rule I use: 401 is "who are you?", 403 is "I know who you are, and no". If you are building an API and want to generate the Authorization headers to test these flows, the Basic Auth Generator produces the encoded credentials you need.
Why do 301 versus 302 redirects matter for SEO?
Redirects are where status codes stop being an internal implementation detail and start affecting your search rankings. When you move a page, the status code you return tells search engines what to do with the old URL's accumulated authority.
A 301 Moved Permanently signals that the move is final. Search engines drop the old URL from their index over time, pass the ranking signals to the new URL, and update their links. This is the code you want when you rename a page, migrate to HTTPS, or consolidate duplicate URLs. Using it correctly is one of the most common fixes in a technical SEO audit.
A 302 Found signals a temporary move. Search engines keep the original URL indexed because you have told them the change is not permanent. If you use a 302 for a move that is permanent, you can strand your ranking on a URL you no longer use. I have seen sites lose visibility for months because a framework defaulted to 302 redirects during an HTTPS migration.
There are also 307 Temporary Redirect and 308 Permanent Redirect, which behave like 302 and 301 but guarantee the HTTP method and body are preserved. Use 307 and 308 for non-GET requests where changing the method would break things. If you are auditing how crawlers see your site, pair this knowledge with the Robots.txt Generator and the Meta Tag Generator to make sure the whole crawl and redirect picture is consistent. The web developer toolkit guide ties these pieces together.
What are the most common server error codes and how do you debug them?
The 5xx class is where production incidents live, and each code points you at a different layer of the stack. Knowing which is which saves real time during an outage.
A 500 Internal Server Error is the generic catch-all. It means your application code threw an unhandled exception or hit a condition it could not process. The fix is almost always in your own logs. A 500 is the server saying "something broke and I have no better word for it", so the code tells you where to look but not what went wrong.
A 502 Bad Gateway and a 504 Gateway Timeout both come from a server acting as a gateway or proxy, such as a load balancer or a reverse proxy in front of your app. A 502 means the upstream sent back something invalid, often because your application crashed or is not running. A 504 means the upstream took too long to respond and the gateway gave up waiting. If you run behind Nginx, a CDN, or a cloud load balancer, these are the codes you will see when the thing behind the proxy is unhealthy.
A 503 Service Unavailable means the server is temporarily unable to handle the request, usually because it is overloaded or in maintenance. Well-behaved 503 responses include a Retry-After header telling clients when to come back. Sending a 503 during planned maintenance is the correct, SEO-safe way to take a site down briefly, because it tells search engines to come back later rather than assuming the pages are gone. For a broader look at diagnosing web issues, the developer productivity tools guide covers the wider toolkit.
What about the less common status codes?
Beyond the working set, the registry holds a long tail of codes that you will meet occasionally, and recognising them saves a confused half hour. A few are worth a quick tour.
In the 2xx family, 206 Partial Content powers resumable downloads and video streaming. When a client sends a Range header asking for bytes 500 to 999 of a file, the server answers 206 with just that slice. This is how a paused download resumes instead of starting over, and how a browser seeks to the middle of a video without fetching the whole thing first.
In the 4xx family, 410 Gone is a stronger, more deliberate version of 404. Where 404 says "I could not find it", 410 says "it was here, it is permanently gone, stop asking". Using 410 for content you have intentionally removed helps search engines drop it faster than a 404 would. Another useful one is 451 Unavailable For Legal Reasons, whose number is a nod to the novel Fahrenheit 451, returned when content is blocked by a legal order such as a takedown or a court injunction.
There is also 418 I'm a Teapot, a real registered code from a 1998 April Fools specification that a teapot returns when asked to brew coffee. It is not used for normal traffic, but it shows up as an easter egg in some APIs, and it is a small reminder that the people who wrote these standards had a sense of humour. The tool lists all of these so you can look up anything you stumble across without guessing.
How does the HTTP Status Codes tool help?
The tool is deliberately simple, because the job is simple: you have a code or a symptom, and you want the meaning fast. You can search by the number, by the reason phrase like "not found", or by a keyword from the description like "redirect" or "rate limit". You can filter to a single class to browse only the redirects or only the server errors. Each entry shows the reason phrase, a plain explanation of when the code applies, and the RFC that defines it, so you can confirm behaviour against the primary source.
Because the entire registry loads in your browser, search is instant and works offline once the page is open. Nothing you search is sent anywhere. It is the kind of reference I keep pinned in a tab while building an API, right next to the User Agent Parser for inspecting request headers.
Frequently asked questions
What are the five classes of HTTP status codes?
HTTP status codes are grouped by their first digit: 1xx informational, 2xx success, 3xx redirection, 4xx client error, and 5xx server error. The class tells you at a glance whether a request succeeded, was redirected, or failed on the client or server side, which is usually enough to know where to start debugging.
What does a 404 status code mean?
A 404 Not Found means the server could not find the requested resource. The URL may be misspelled, the page may have been deleted, or the link may be broken. It is a client-error code, so the request reached the server but pointed at something that does not exist there.
What is the difference between a 301 and a 302 redirect?
A 301 Moved Permanently tells clients and search engines the resource has moved for good, so they update their links and transfer ranking signals to the new URL. A 302 Found is a temporary redirect, so the original URL should keep being used for future requests and search engines keep it indexed.
What does a 500 Internal Server Error mean?
A 500 Internal Server Error is a generic message meaning the server hit an unexpected condition it could not handle. It signals a problem on the server rather than the request, so the fix is usually in the application code or configuration, and your own server logs are the place to look.
When should an API return 400 versus 422?
Return 400 Bad Request when the request itself is malformed, such as invalid JSON or a missing required header. Return 422 Unprocessable Content when the syntax is valid but the data fails business or validation rules, such as an email that is already taken or a value out of range.
What is a 429 Too Many Requests code?
A 429 Too Many Requests means the client has sent too many requests in a short time and is being rate limited. The response often includes a Retry-After header telling the client how long to wait before trying again, and well-behaved clients honour it with an exponential backoff.
Is the HTTP status code reference free to use?
Yes. The tool is completely free with no signup and no limits, and it works offline once the page has loaded because the entire list runs in your browser. Nothing you search is sent to a server, so it is safe and fast to use while debugging.
