What HTTP Status Code Lookup does
An HTTP status code is the server's one-line verdict on a request, and the first digit tells you most of what you need: 2xx worked, 3xx means go elsewhere, 4xx blames the request and 5xx blames the server. Search by number to get the full explanation for a single code, or by keyword to find every code relating to redirects, authentication or timeouts. Each entry says what the code means, whether responses carrying it are cacheable by default, and the cause you should check first — which is usually more useful than the formal definition when something is broken.
Using HTTP Status Code Lookup
- 1
Enter a status code such as 404, or a keyword such as 'redirect' or 'gateway'.
- 2
Narrow the results to a single class if you only care about client or server errors.
- 3
Read the detail panel for an exact code match, including its usual cause.
- 4
Scan the table for related codes — the neighbouring ones are often what you actually want.
Common uses
Debugging a failing API call
The status code narrows the problem immediately: 401 and 403 point at auth, 422 at validation, 502 and 504 at something behind the proxy.
Choosing the right redirect
301, 302, 307 and 308 differ in permanence and whether the HTTP method is preserved, and picking wrongly has lasting SEO consequences.
Designing an API
Returning the semantically correct code lets clients handle responses generically instead of parsing error messages.
Reading server logs
A sudden rise in a particular code is often the fastest signal of what changed, before any alert fires.
Why the first digit is the part that matters
Status codes are deliberately designed so a client that has never seen a specific code can still handle it correctly, purely from its class. A client encountering 418 or some future 4xx code knows the request was at fault and that retrying it unchanged will not help, without needing to know what the code means. That is why the classes are worth internalising before the individual numbers: 1xx is informational and rarely surfaces in application code; 2xx means the request succeeded; 3xx means the resource is somewhere else or unchanged; 4xx means the client sent something the server will not accept; and 5xx means the request was reasonable but the server failed to fulfil it. The 4xx and 5xx split is the operationally important one, because it decides who is responsible: a spike in 4xx points at clients, an integration or a bad deploy of a front end, while a spike in 5xx points at your own servers and is almost always the more urgent of the two.
The distinctions that cause the most trouble
Four pairs account for most of the confusion in practice. 401 versus 403: 401 means authentication is missing or invalid and retrying with good credentials may work, while 403 means the identity is known and still not permitted, so retrying is pointless. 301 versus 302: 301 is permanent and browsers cache it aggressively — sometimes until the cache is manually cleared — so an incorrectly issued 301 is genuinely hard to undo, whereas 302 is temporary and safely reversible. 302 versus 307: historically many clients turned a redirected POST into a GET on a 302, so 307 and 308 exist to guarantee the method and body survive the redirect. Finally 404 versus 410: both mean the resource is not here, but 410 asserts the removal is permanent and search engines drop the URL faster as a result, while 404 leaves the door open and crawlers keep retrying for longer.
Tips
- Use 307 or 308 for any redirect on an endpoint that receives POST requests, so the method and body are preserved.
- Return 429 with a Retry-After header when rate limiting, so well-behaved clients back off instead of hammering you.
- Reserve 500 for genuinely unexpected failures — using it for validation errors hides real faults in your monitoring.