These two codes are routinely swapped, including by servers that should know better, and the confusion costs real debugging time. The rule is short: 401 is about authentication (who are you?), 403 is about authorization (you are known, and not allowed). Everything else follows.
401 Unauthorized ¶
The name is a historical misnomer — it should have been "Unauthenticated". A 401 means credentials were missing, malformed, or expired. A correct 401 comes with a WWW-Authenticate header telling the client how to authenticate; the presence of that header is how you know you are looking at a real 401 rather than a mislabelled 403.
The useful implication: retrying with valid credentials should work. A 401 is an invitation to try again, properly.
403 Forbidden ¶
The server understood who you are and is refusing anyway. Logging in again will not help — either the account lacks permission, or something in front of the application (a WAF, a geo-block, an IP allowlist) decided you do not get through. Our deeper 403 guide covers the blocked-versus-broken distinction.
| Situation | Correct code | What to do |
|---|---|---|
| No credentials sent | 401 | Log in / send a token |
| Token expired | 401 | Refresh the token |
| Valid login, no permission | 403 | Get access granted; retrying won't help |
| Blocked by WAF or country | 403 | Not an account problem at all |
| Hiding a resource's existence | 404 (deliberately) | Nothing — by design |
The 403-that-should-be-404 case ¶
Security-conscious APIs sometimes return 404 where 403 is technically correct, so that an attacker cannot enumerate which resources exist by watching for the difference between "forbidden" and "not there". If you get a 404 for something you are certain exists, permissions are a likelier explanation than deletion.
Telling an auth problem from an outage ¶
Both 401 and 403 prove the server is running — it evaluated your request and made a decision. If you want to know whether the service itself is healthy rather than whether you personally can get in, probe an unauthenticated endpoint like the homepage. A site that answers 401 on its API and 200 on its homepage is up; your credentials are the problem.
What each code means for a retry ¶
The distinction is not academic if you are writing a client. A 401 means "these credentials were not accepted" — the correct response is to refresh the token or re-authenticate once, then retry. A 403 means "this identity is not permitted" — retrying is pointless, and a client that retries a 403 in a loop is generating load for nothing and will often trip a rate limiter into the bargain.
The practical rule: retry a 401 exactly once, after refreshing credentials. Never retry a 403 automatically. Surface it to a human, because only a human can get permissions changed.
Why servers get this wrong so often ¶
Frameworks routinely return 403 for "not logged in", because the middleware that checks the session cannot easily produce a meaningful WWW-Authenticate header and 403 needs no such thing. The result is that a large share of real-world 403s are actually 401s in disguise, which is why "log in again" is worth trying even when the code says forbidden.
If you are on the other side of that: send 401 with a WWW-Authenticate header when authentication is missing or stale, and reserve 403 for decisions you have genuinely made about a known identity. It costs nothing and it tells every client exactly what to do next.
FAQ ¶
Why do I get 403 after logging in successfully?
Because authentication succeeded and authorization failed. The system knows who you are and your account does not have rights to that resource. Only an administrator can change that.
Does a 401 mean my password is wrong?
Not necessarily — it means the credentials presented were not accepted. An expired session token produces the same code as a wrong password. Re-authenticating covers both.
Is 401 or 403 a sign the website is down?
Neither. Both are considered replies from a working server. Check an unauthenticated page to see whether the service itself is healthy.