What are the five HTTP status code classes?

Status codes are grouped by their first digit. 1xx are informational (interim responses), 2xx are success, 3xx are redirection, 4xx are client errors (the request was wrong), and 5xx are server errors (the server failed on a valid request). Knowing the class alone tells you who is at fault and roughly what happened.

What is the difference between 401 and 403?

A 401 Unauthorized means you are not authenticated — no valid credentials were supplied, so sending correct ones may fix it. A 403 Forbidden means you are authenticated but lack permission for this resource, so retrying with the same identity will never succeed. In short, 401 is who are you and 403 is you are not allowed.

When should I use 301 versus 302 versus 307?

Use 301 Moved Permanently when a URL has changed for good so clients and search engines update their links. Use 302 Found for a temporary move, though historically it could change POST to GET. Use 307 Temporary Redirect when you need a temporary redirect that preserves the original method and body, and 308 for a permanent one that preserves the method.

What status code should a successful POST return?

If the request created a new resource, return 201 Created with a Location header pointing at it. If it kicked off asynchronous work, return 202 Accepted. If it succeeded but has nothing to send back, 204 No Content is appropriate. A plain 200 OK is fine when you are returning the result in the body.

What is the right code for rate limiting or maintenance?

For rate limiting, return 429 Too Many Requests with a Retry-After header telling the client how long to wait. For planned downtime or overload, return 503 Service Unavailable, also with Retry-After. Avoid using a generic 500 for these — the specific codes let clients and proxies behave correctly.

Is this HTTP status code reference free and private?

Yes. The entire reference, search, filtering and your saved codes run in your browser with no account and no network calls. Saved codes are stored only in this browser via localStorage, so nothing you do here is ever uploaded.

HTTP Status Codes Reference

The HTTP Status Codes Reference is a searchable, filterable lookup for every common HTTP response code — from 100 Continue to 504 Gateway Timeout. Each entry gives you the plain-English meaning, concrete when-to-use guidance, and the practical details developers actually need: which spec defines it, whether the response normally carries a body, and how it interacts with caching. It is built for backend and API engineers, frontend developers debugging a fetch, QA testers reading network logs, and anyone who has ever squinted at a number in the DevTools network tab and wondered what their server is really trying to say.

Most status-code lists are static walls of text. This one is interactive: start typing and the list narrows in real time, whether you search by number (429), by name (Conflict), or by concept (redirect, rate limit, validation). Class chips let you jump straight to the family you care about, and a star lets you pin the codes your team relies on so they are one tap away next time.

How it works

Every code is grouped into one of five classes by its first digit: 1xx informational, 2xx success, 3xx redirection, 4xx client errors, and 5xx server errors. Knowing the class is half the battle — a 4xx tells you the request was wrong, a 5xx tells you the server broke on an otherwise valid request. The tool keeps your search query and active filter in component state, recomputes the matching set on every keystroke, regroups the results by class, and renders each group with a colour-coded badge so the right answer is easy to scan. Click any code to expand its when-to-use note and metadata; tap the star and your choice is written to localStorage so a dedicated Saved view survives page reloads. Nothing leaves your machine — there are no network requests at all.

Example

Suppose a form submission to your API keeps failing. You open this reference, type 422, and read that 422 Unprocessable Content means the JSON parsed fine but a business rule was violated — so the bug is validation logic, not malformed input. You then compare it with 400, confirm 400 is for genuinely malformed requests, and decide 422 with a field-level error body is the correct response. Finally you star both codes and 201 Created for your team’s API style guide, copy each one-line summary, and paste them straight into your documentation.

Code	Name	Use it for
200	OK	Successful GET returning data
201	Created	POST that created a new resource
204	No Content	Successful DELETE with nothing to return
401	Unauthorized	Missing or invalid credentials
404	Not Found	The URL maps to nothing
429	Too Many Requests	Client hit the rate limit
503	Service Unavailable	Maintenance or overload

Everything — search, filtering and your saved list — runs entirely in your browser, with no account and nothing uploaded.