Developer Tools·5 min read

HTTP Status Codes Explained: 3xx, 4xx, 5xx Decoded

Every HTTP response starts with a three digit number, and that number often tells you more than the error page beneath it. You don't need to memorize sixty entries. You need five families: 1xx is information, 2xx is success, 3xx is redirection, 4xx means the client got something wrong, and 5xx means the server did. This article covers the codes you'll actually debug, walks through a redirect story where 301 and 308 behave very differently, and looks at what redirects and downtime signals do to search crawling.

Open the free HTTP Status Codes List All insights

HTTP status codes explained by their first digit

Five families, one triage system.

The first digit sorts every response into a family. 1xx codes are procedural chatter, like 100 Continue telling a client to keep sending. 2xx means the request worked, whether that's a plain 200 OK or a 204 No Content after a successful delete. 3xx says look elsewhere. 4xx puts the blame on the client: bad syntax, missing auth, a URL that doesn't exist. 5xx admits the server broke.

That single digit is your triage system. Before reading logs or stack traces, the family tells you which side of the wire to investigate, and that alone rules out half the possible causes. The HTTP Status Codes List mirrors this with a button per family, so pressing 4xx narrows the table to client errors.

Debugging a page that redirects or errors out

Say a page loads blank, or bounces you somewhere unexpected. Open the browser's Network panel, reload, and read the status column top to bottom. A sequence like 301 into 302 into 200 exposes every hop of a redirect chain users never see. A single 500 on one API call, buried under twenty green 200s, pinpoints the one backend route that's actually failing.

The lookup table earns its place in exactly this moment. Spotting 422 in the panel and reading that the syntax is fine but the content fails validation turns a mystery into a task: fix the payload shape, not the route. When you'd rather not open DevTools at all, the HTTP Status Code Checker reports what a live URL returns, and the Redirect Checker traces each hop of a chain.

Each code in the list has its own link, so you can drop a URL ending in #code-422 into a ticket and the reader lands on the right row with its meaning and SEO note.

A redirect story: why 301 and 308 aren't twins

Same permanence, very different handling of your data.

Imagine you move a signup endpoint from /signup to /register, and the old route answers with a redirect. Which code you pick decides what happens to the data in flight.

With a 301: the client sends POST /signup with a JSON body, receives 301 with Location: /register, and most clients follow up with GET /register carrying no body at all. The form data evaporates, signups fail, and nothing errors loudly.

With a 308: the spec forbids changing the method, so the client repeats POST /register with the body intact and the signup completes. That's the entire distinction. 301 and 302 permit the method to collapse into GET, while 307 and 308 preserve it, so anything that isn't a plain GET deserves the modern pair.

301 vs 302, and what each does to your SEO

For search engines the 301 vs 302 choice is a statement of intent. A 301 is a strong signal that the move is permanent and the new URL should be indexed instead. A 302 is a weak signal, so Google usually keeps the original URL in results. Shipping a 302 on a permanent migration can leave the old address ranking in place of the new one for a long time.

Downtime has its own vocabulary too. A maintenance window served as 503, ideally with a Retry-After header, reads as temporary: crawlers slow down and come back later instead of dropping pages. If the 503s continue for a long time, URLs may start falling out of the index. Serving an error page with a 200 during the same outage is worse, because crawlers treat it as a soft 404 rather than a temporary outage.

Status code habits that hide real problems

A few patterns show up in almost every codebase audit:

Returning 200 with an error message in the body. Monitoring, caches, and crawlers all read the 200 and record a success that never happened.
Blurring 401 and 403. Unauthorized means the server doesn't know who you are; Forbidden means it knows precisely who you are and the answer is still no.
Ignoring Retry-After on a 429 and retrying harder, which typically stretches the rate limit into a block.
Answering validation failures with 500. A malformed payload deserves a 400 or 422 so the client knows the fix is on its side.
Debugging 499 or 52x codes in the browser. 499 is logged by nginx when the client gives up, and Cloudflare's 520 to 526 describe trouble between Cloudflare and your origin, so the fix usually lives on the origin server.

Three checks worth making before you open the logs

Run curl -I against the failing URL to read the raw status line with browser caching out of the picture. Search the list by symptom words, since the search covers the Meaning column: typing timeout surfaces 408, 504 and the Cloudflare timeouts without knowing a single number. And keep the gateway trio straight: 502 means the upstream answered garbage, 504 means it never answered, and 503 means the service itself asked for a breather.

One naming note: the list uses the current RFC 9110 names, so 413 is Content Too Large and 422 is Unprocessable Content. Older docs and frameworks still say Payload Too Large and Unprocessable Entity. The Source column marks unofficial codes from nginx, Cloudflare, IIS, AWS load balancers and proxies, and the Unofficial button shows only those. The Common button trims the table to the twenty codes most people meet, and the SEO notes button keeps only the codes that change how search engines crawl and index a page.

Neighboring tools for the same investigation

Status codes rarely misbehave alone. When a request needs rebuilding to test a fix, the cURL to Code Converter turns the command you copied into fetch, Python, Go or any of 16 other targets. If the domain won't resolve at all, no HTTP status exists yet, and that's a job for the DNS Record Types reference. And when a 200 response still renders wrong, the MIME Type Lookup usually explains why the browser mistreated a perfectly delivered body.