📡 HTTP Status Code Lookup
Instantly search HTTP status codes (1xx–5xx) by code number or keyword. Concise explanations of each code's meaning, common causes, and troubleshooting steps.
🔗 Related Tools
📖 Where people get stuck
A list you can search by number or by keyword. What it cannot tell you is which code your own site actually returns — that is the job of the HTTP header check and the redirect chain check. The thing worth internalising is that a status code classifies what happened, not whose fault it was. The 4xx-versus-5xx split is a starting point only; plenty of applications swallow a server error and return 200 anyway.
| Case | What happens | What to do |
|---|---|---|
| Meant to return 404, actually returned 200 | The page looks like an error but ships with a 200. Google calls this a soft 404 and flags it in Search Console. It happens constantly with SPAs that resolve routing only on the client, and with CMSes that render a no-results page from a template. | Make the status line agree with the body. Return 404 for a URL that does not exist, 410 when you deleted it for good, and 503 with a Retry-After during maintenance. Even in a SPA the server can decide whether a route exists and at least get the status line right. Verify with curl -I or the HTTP header check — looking at the rendered page tells you nothing. |
| Confusing 401 with 403 | 401 means we do not know who you are; 403 means we know and you still may not. The names Unauthorized and Forbidden read backwards, but 401 is about authentication and 403 about authorisation. When a logged-in user reaches for somebody else resource, 403 is correct — return 401 and the client will prompt for login again even though the credentials were fine. | Always send a WWW-Authenticate header with a 401 — the specification requires it, and a 401 without one is strictly malformed. When you need to hide the very existence of a resource, the convention is to return 404 rather than 403, so the response leaks nothing: admin URLs and other people order IDs are the usual cases. |
| Retrying immediately after a 429 | Throwing the same request straight back after a rate limit extends the block and eventually gets your IP cut off entirely. When several clients retry in lockstep you also get the thundering herd: everyone hits at the same instant the window opens. Unconditional retries on 5xx do the same thing — they pile load onto a server that is already failing. | Honour Retry-After whenever it is present — it holds either seconds or an HTTP date. Without it, use exponential backoff with jitter: 1s, 2s, 4s, 8s, each multiplied by a random factor of roughly ±50 %. Skip the jitter and every client that failed together keeps retrying together. Retry only 408, 429, 500, 502, 503 and 504; a 400 or a 422 means the input is wrong and will fail identically every time. |
3xx responses are cached hard by browsers. A 301 in particular declares itself permanent, and many browsers remember it with no expiry at all, so reverting the server does not stop the redirect on a user machine. Send a 301 by mistake during testing and the affected users stay redirected until they clear their cache. Use 302 or 307 until the configuration has settled, and only then switch to 301 or 308. It is one of the least reversible mistakes in redirect configuration.
❓ Frequently Asked Questions
When should I use 410 instead of 404?
What is the difference between 502 and 504?
When should a redirect be 308 rather than 301?
🐛 Found a bug or issue with this tool?
Free to use, no signup. Even just the steps to reproduce are helpful. Reports go directly to the operator and help us fix issues.
Thanks for your report!
Your report has been delivered to the operator and will be used to improve the tool.