HTTP Status Codes List Explained: 401 vs 403, 502 vs 503

Picture this: you click a button on the page you're building, and the data that should appear just doesn't. Your first instinct is to open the code and hunt for the mistake. But the first thing worth looking at is not a single line of code. It is one three-digit number the server sent back. That number tells you in the first second which side the problem lives on. If it starts with 4, go back and look at your own request. If it starts with 5, you could rewrite your front-end all night and nothing would change.

Today Superdev Academy walks through which HTTP status codes exist, which ones beginners actually run into, how to tell 401 from 403 and 502 from 503, and how to see the number for yourself in your browser's DevTools.

Why read the status code before you read the code

Every time a browser or your code sends a request to a server, the server sends back a response with a status code: always a three-digit number. If the idea of requests and responses is still new, read What is an API alongside this one, then come back.

RFC 9110, the document that defines what HTTP means, is clear on this: the first digit defines the class of the response, the last two digits have no categorisation role at all, and every valid status code falls between 100 and 599. That is why we always start with the first digit. One digit already cuts the search space in half.

This habit is part of debugging well. For the bigger picture of what to do first when you hit a bug, read What to do first when debugging: read errors, Google, or ask AI?

HTTP status codes list: 5 classes from the first digit

The short version to remember: 2xx success / 3xx moved / 4xx requester's fault / 5xx server broke. The 1xx class is one beginners almost never see directly. This table summarises all 5 classes as RFC 9110 defines them.

One more rule is surprisingly useful. RFC 9110 says a client does not have to understand every registered code, but it must understand the class from the first digit, and treat any code it does not recognise as the x00 code of that class. The RFC's own example: an unknown 471 should be treated like a 400, because the first digit already says something was wrong with the request. In other words, even if you remember no codes at all, the first digit points you in the right direction.

Fun Fact: MDN's status code reference lists 418 I'm a teapot. It comes from RFC 2324, an April Fools' joke about a protocol for controlling coffee pots. It is not a code you need in real work.

2xx and 3xx: mostly nothing to fix

200 OK means the request succeeded. What comes back depends on the method: a GET returns the resource you asked for. It is the code you see most when everything works.

201 Created means the request succeeded and a new resource was created. You usually meet it after a POST that signs someone up or adds a new record. RFC 9110 says the new resource is identified by a Location header when one is sent.

204 No Content means the request succeeded but there is no content in the response at all. It is common after deleting something or saving a value that needs no reply. The classic beginner mistake is code that always parses JSON from the response without checking first. Hit a 204 and you get an error even though the request already succeeded.

301 Moved Permanently and 302 Found are redirects. The difference: 301 is a permanent move, 302 a temporary one. The new address comes in the Location header and the browser follows it automatically.

304 Not Modified looks odd but is not an error. It happens when the browser asks the server "has this file changed?" and the server says no, so the browser uses the copy already in its cache instead of downloading it again.

4xx: something is wrong with your request

Whenever you see this class, look at what you sent first: the URL, the method, the headers and the body.

400 Bad Request means the server will not process the request because it sees a client-side error, such as malformed syntax. In API work it usually shows up when the JSON you sent is malformed or a required field is missing. RFC 9110 also defines 422 Unprocessable Content for a request whose syntax is fine but whose contents the server cannot process, which many APIs use for data that fails validation, so always read the response body too.

404 Not Found means the server found nothing for what you asked. The most common causes are a misspelled URL, a missing or extra slash, or an endpoint that has not been deployed yet. RFC 9110 also notes that 404 does not say whether the absence is temporary or permanent; if the server knows it is gone for good, 410 Gone is preferred.

429 Too Many Requests comes from RFC 6585 and means you sent too many requests in a given amount of time, which is called rate limiting. The server may include a Retry-After header saying how long to wait. What you should not do is write a loop that retries instantly, because hammering the server keeps you over the quota and some systems will limit you for longer.

401 and 403 get their own section, because they are the pair people confuse most.

401 vs 403: what is the difference?

The name 401 Unauthorized is misleading from the start. By the RFC 9110 definition, a 401 means the request was not applied because it lacks valid authentication credentials. Put simply, the server does not yet know who you are. A server sending 401 must also send a WWW-Authenticate header describing how to authenticate.

403 Forbidden means the server understood the request but refuses to fulfil it. RFC 9110 says that if the request did include credentials, the server considers them insufficient, and the client should not simply repeat the request with the same credentials.

• Got a 401: check whether you attached a token at all, whether it has expired, whether the header name is spelled correctly, and whether you are using the right API key.

• Got a 403: your identity is fine, but this account is not allowed to do this. You need more permissions, not another login attempt.

If you are working with an API that needs a key, read how to keep your API key safe in a .env file as well, because a key that fails to load or a misspelled variable name is a very common cause of 401.

5xx: the server broke

This class means your request looks valid, but the server failed to handle it. Clearing your cache or editing your front-end code will not help.

500 Internal Server Error means the server hit an unexpected condition that stopped it from fulfilling the request. It is the broadest code in the class. If you wrote the back-end yourself, the place to look is the server log, not the browser console. To see how a back-end sets status codes in real code, read JS2GO EP.30 Handling HTTP Requests and Responses.

502 vs 503: what is the difference?

Both involve a part of the system beginners rarely see. In real deployments your request usually does not go straight to the app. It passes through something in the middle first, such as Nginx or a load balancer acting as a gateway or proxy that receives requests and forwards them.

502 Bad Gateway means that middle layer called the server behind it and got an invalid response back. The gateway itself is working, but whatever sits behind it has a problem, for example the app behind it has crashed.

503 Service Unavailable means the server cannot handle the request right now because of a temporary overload or scheduled maintenance. RFC 9110 says this will likely be alleviated after some delay, and the server may send a Retry-After header, just like with 429.

In one sentence each: 502 is "the thing behind me answered with garbage", 503 is "I can't take this right now, give me a moment". The similar-looking 504 Gateway Timeout means the middle layer waited too long for the server behind it and gave up.

How to see status codes in the DevTools Network tab

You do not need to install anything. Every major browser already ships this tool. In Chrome or Edge:

1. Press F12 or Ctrl+Shift+I on Windows (Cmd+Option+I on Mac) to open DevTools.

2. Choose the Network tab and reload the page, because DevTools only records requests made after the tab is open.

3. Look at the Status column to see the code for every request.

4. If you only care about API calls, click the Fetch/XHR filter to hide images and CSS.

5. Click the failing row. The Headers tab shows the status code and every header; the Response tab shows what the server actually sent back.

If the list clears when the page navigates, tick Preserve log to keep it. These steps pair well with the mindset in What is debugging and why good programmers must be great at fixing bugs: collect evidence before you guess.

Does the status code always tell the truth?

Not always, and it is worth knowing before you trust the number completely. RFC 9110 allows a server that wants to hide whether something exists to answer 404 instead of 403. So some of the 404s you see actually mean you lack permission, not that the URL is wrong.

RFC 9110 also admits that an overloaded server does not have to answer 503. Some simply refuse the connection, and then there is no status code to read at all. And in practice, some APIs return 200 for everything and put the error inside the response body.

So the rule that actually works: read the status code to decide which side to look at first, then open the Response tab and read what the server sent, every time.

The number points the way. The body is the evidence.

Summary: you have the number, where do you start?

HTTP status codes fall into 5 classes by the first digit, and what you really need to remember is this: 2xx success / 3xx moved / 4xx requester's fault / 5xx server broke. On a 4xx, go back to your URL, your token and the data you sent. On a 5xx, check the server log or tell whoever runs the server. 401 means the server does not know who you are yet, 403 means it knows and still says no, 502 means the server behind the gateway answered badly, and 503 means the server is temporarily unable to cope.

Open the Network tab on the site you are building right now and count how many requests are not 2xx. Next time you hit a bug, you will start from one number instead of guessing across a whole file. For the full definitions, open RFC 9110, Status Codes, RFC 6585, 429 Too Many Requests and MDN's HTTP response status codes reference.

Follow more articles and tips for people starting out as programmers on our channels.

Facebook: Superdev School (Superdev) — https://www.facebook.com/superdev.school.th

Instagram: superdevschool — https://www.instagram.com/superdevschool/

TikTok: superdevschool — https://www.tiktok.com/@superdevschool

Website: www.superdevacademy.com — https://www.superdevacademy.com/