HTTP Status Codes Explained: The Complete Developer Guide

PAYATE Team· Oct 29, 2026· 6 min read

Every HTTP response carries a three-digit status code, and that number is the server's one-word verdict on your request. Learn to read it and most debugging stops being guesswork: you instantly know whether the problem is on your side, the server's side, or just a redirect doing its job. This guide maps the codes by class, covers the ones you will actually meet, and clears up the pairs that get confused.

The five classes, at a glance

The first digit of a status code tells you its category. Memorise just these five ideas and you can place any code you have never seen before:

1xx — Informational: "Received, continuing." Rare in everyday work.
2xx — Success: "It worked."
3xx — Redirection: "Look somewhere else."
4xx — Client error: "You made a mistake."
5xx — Server error: "I made a mistake."

That 4xx-versus-5xx split is the single most useful distinction. A 4xx tells you to fix your request; a 5xx tells you the request was fine but the server failed, so retrying or checking server logs is the right move.

2xx — Success

200 OK — the standard "all good" response with a body.
201 Created — a new resource was created, typically after a POST. Well-behaved APIs return the new resource's location.
202 Accepted — the request was accepted but will be processed later, common for asynchronous jobs.
204 No Content — success with nothing to return, often after a DELETE or an update where the body would be pointless.

If you build APIs, using 201 and 204 correctly instead of a blanket 200 makes your responses self-documenting.

3xx — Redirection

A 3xx is not an error; it is a signpost. The distinction between permanent and temporary matters a lot for SEO and caching:

301 Moved Permanently — the resource lives at a new URL forever. Search engines transfer ranking to the new address, and browsers cache it aggressively.
302 Found / 307 Temporary Redirect — a temporary move; do not cache it as permanent. 307 is the stricter modern version that preserves the request method.
304 Not Modified — your cached copy is still current, so the server sends no body. This is the backbone of efficient caching.
308 Permanent Redirect — like 301 but, like 307, it keeps the original method.

Getting 301 versus 302 right is one of the most common real-world SEO fixes: a temporary redirect where a permanent one belongs quietly throws away ranking signals.

4xx — Client errors (the ones you will see most)

These say the request was wrong. The code points at what was wrong:

400 Bad Request — the server could not parse the request at all. Malformed JSON is the classic cause; validating your payload with a JSON formatter before sending catches most of these in seconds.
401 Unauthorized — you are not authenticated. The server does not know who you are. Send valid credentials or a token.
403 Forbidden — you are authenticated but not allowed. More credentials will not help; you lack permission.
404 Not Found — the resource does not exist at this URL. Also used, deliberately, to hide resources you are not meant to know about.
405 Method Not Allowed — the URL exists but not for this verb (for example a GET where only POST is accepted).
409 Conflict — the request clashes with the current state, such as creating something that already exists.
422 Unprocessable Entity — the request was well-formed and understood, but failed validation rules. This is the right code for "your email field is not a valid email," not 400.
429 Too Many Requests — you hit a rate limit. Back off and respect the Retry-After header if present.

401 vs 403 vs 404 — the classic confusion

Think of a members-only building. 401 is the front desk asking for your ID because you have not shown one. 403 is the desk recognising you but telling you this floor is off-limits. 404 is being told the room you asked for does not exist. Using the right one makes an API far easier to integrate against.

5xx — Server errors

These mean your request was acceptable but the server could not fulfil it. The problem is not on your side:

500 Internal Server Error — a generic "something broke" with no more detail. Check the server logs; the real cause is there.
502 Bad Gateway — a server acting as a proxy got an invalid response from an upstream server. Common behind load balancers and reverse proxies.
503 Service Unavailable — the server is temporarily overloaded or down for maintenance. It is meant to be transient, so retrying later is reasonable.
504 Gateway Timeout — a proxy waited for an upstream server and gave up. Usually a slow or stuck backend.

When you see 502, 503, or 504, the shape of the failure often points at infrastructure — DNS, upstream health, or timeouts — rather than your code. A quick DNS lookup can rule out a name-resolution problem before you dig into application logs.

A quick decision tree for a failing request

Is it 4xx? Fix the request. Check the method, the URL, your auth, and your payload.
Is it 5xx? The request was fine. Look at server logs, upstream services, and timeouts; retrying may succeed.
Is it 3xx? Nothing is wrong. Confirm your client follows redirects and that permanent versus temporary is set correctly.
Is it 401 or 403? 401 means authenticate; 403 means you are authenticated but lack permission.

Headers that travel with the code

A status code rarely stands alone. A 429 should carry Retry-After; a 301 carries Location; a 405 should list the allowed methods in Allow; and caching codes lean on ETag and Cache-Control. Reading the headers alongside the code usually turns "why did this fail?" into a precise answer.

Designing APIs that use codes honestly

If you publish an API, the fastest way to make it pleasant is to use status codes truthfully instead of returning 200 with an error buried in the body. Return 201 when you create, 204 when there is nothing to send back, 401 versus 403 precisely, 422 for validation failures, and real 5xx codes when your side breaks. Integrators can then handle your API with standard logic instead of parsing every response to guess what happened.

The takeaway

HTTP status codes are a compact, universal language. The first digit tells you the class, the 4xx-versus-5xx line tells you whose problem it is, and a handful of specific codes — 301, 401, 403, 404, 422, 429, 500, 503 — cover almost everything you will meet in practice. Once the numbers stop being noise and start being sentences, debugging the web gets dramatically faster.

Frequently asked questions

What are the five classes of HTTP status codes?

1xx informational, 2xx success, 3xx redirection, 4xx client errors, and 5xx server errors. The first digit tells you the category at a glance, so 404 is a client error and 503 is a server error.

What is the difference between 401 and 403?

401 Unauthorized means you have not authenticated — the server does not know who you are, so send valid credentials. 403 Forbidden means you are authenticated but not allowed to access this resource; sending credentials again will not help.

Is a 3xx redirect an error?

No. A 3xx status is a normal instruction to look somewhere else. 301 is a permanent move and 302 or 307 are temporary. Clients follow them automatically, so users rarely notice.

When should an API return 422 instead of 400?

400 Bad Request means the request was malformed and the server could not parse it. 422 Unprocessable Entity means the request was well-formed and understood, but the data failed validation rules, such as an email field that is not a valid email.

Try the tools

JSON Formatter →Dns Lookup →IP Lookup →Base64 →

Written by PAYATE Team

The PAYATE team builds free tools for merchants and developers.