Developer Tools·4 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. Getting http status codes explained properly means learning five families, not memorizing sixty entries: 1xx is information, 2xx is success, 3xx is redirection, 4xx means the client messed up, 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 your search rankings.

Open the tool 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.

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 request was well-formed but semantically wrong turns a mystery into a task: fix the payload shape, not the route.

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 tells crawlers the move is permanent: index the new URL, transfer the ranking signals, forget the old address. A 302 says the original URL will return, so Google keeps it indexed and the destination page accumulates little authority of its own. Shipping a 302 on a permanent migration is one of the quietest ways to bleed rankings.

Downtime has its own vocabulary too. Part of what 503 means for SEO is that a maintenance window served as 503 with a Retry-After header reads as temporary, and crawlers return later without penalty. Serve a 404 or a soft error page with a 200 during that same outage, and pages start falling out of the index.

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.

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 this table by symptom words, since the filter matches description text, so typing timeout or cache lands on the right row without knowing the 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.

Neighboring tools for the same investigation

Status codes rarely misbehave alone. When a request needs rebuilding to test a fix, cURL to Code turns the command you copied into fetch, axios, or Python. 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.