Is 401 the same as 403 Forbidden?

No, and this is the distinction that matters. RFC 9110 defines 401 as missing or invalid authentication — the server doesn't know who you are. 403 means the server knows who you are and is refusing anyway. Sending credentials can fix a 401; it will not fix a 403, because a 403 is about permission, not identity.

Why does a 401 sometimes have no login prompt?

A spec-compliant 401 MUST include a WWW-Authenticate header telling the client how to authenticate (RFC 9110 §15.5.2). APIs often omit it or return a 401 for an expired token instead of a real challenge, so the browser never pops a login box. If the header is missing, the server is technically out of spec — and that's often the clue that a token, not a password, is what's being rejected.

My credentials are correct but I still get 401. Why?

The usual culprits are an expired or malformed token, a clock skew that invalidated a time-based token, or a proxy that stripped the Authorization header before it reached the origin. The credentials were fine; they just didn't arrive intact or in time.

Views: 143

401 Unauthorized: Fix Rejected or Missing Credentials

401 Unauthorized? Credentials are missing or rejected. Tell an expired token from a stripped header from a 403 in 3 checks. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

A request returns 401 Unauthorized. The server received it but refused to act because it has no valid authentication for the target resource.

Symptoms

HTTP Check shows a final status code of 401.
A browser may show a login prompt, or an API may return a JSON body like {"error":"invalid_token"}.
It hits authenticated routes (an API, a /admin path, a private endpoint) while the public homepage loads fine.
The same request worked yesterday and fails today — a hallmark of an expired token or session.

What 401 Actually Means

RFC 9110 (§15.5.2) defines 401 as “the request has not been applied because it lacks valid authentication credentials for the target resource.” The server isn’t broken and isn’t hiding — it simply doesn’t know who you are, or the proof you sent didn’t check out.

The part people skip: a 401 response MUST carry a WWW-Authenticate header with at least one challenge describing how to authenticate. That header is the whole point of 401. It’s the server saying “here’s the scheme I want — Basic, Bearer, whatever — try again with that.” When you get a 401 with no WWW-Authenticate header, the server is out of spec, and in practice that almost always means a token-based API rejected an expired or malformed bearer token rather than issuing a genuine challenge.

That’s also why 401 gets confused with 403, and getting them backwards wastes hours. 401 is authentication: who are you. 403 is authorization: I know who you are, you still can’t. Sending credentials is the fix for a 401. Sending credentials does nothing for a 403 — you’re already identified, and the answer is still no.

Top 3 Causes

Missing, expired, or malformed credentials - No Authorization header at all, an access token past its expiry, a rotated API key, or a JWT that’s the wrong shape. This is the overwhelming majority of real 401s, and expiry is the single most common trigger.
A proxy or gateway stripping the Authorization header - A reverse proxy, load balancer, or CDN drops or rewrites the Authorization header before it reaches the origin, so the app sees an unauthenticated request even though the client sent valid credentials. Redirects that change scheme or host also cause browsers to drop the header.
Clock skew invalidating a time-based token - JWTs and signed tokens carry iat/exp claims. If the client or server clock drifts by more than the allowed leeway, a perfectly valid token reads as expired or not-yet-valid, and every request comes back 401.

Diagnose with DechoNet

HTTP Check to confirm the final code is truly 401, and — critically — to read the response headers. A present WWW-Authenticate header tells you the expected auth scheme; a missing one points straight at a token being rejected rather than a real challenge.

Resolution Checklist

Read the WWW-Authenticate header on the 401. It names the scheme the server expects (Basic, Bearer, etc.). No header usually means a token was rejected silently.
Confirm you’re actually sending credentials — inspect the outgoing Authorization header in the browser network tab or with curl -v.
If it’s a token, decode it and check exp. Refresh or re-issue and retry; expiry is the most likely cause.
Rule out a stripped header: compare a request straight to the origin against one through the proxy/CDN. If the origin accepts it and the proxy doesn’t, the proxy is dropping Authorization.
Check client and server clocks if you use time-based tokens — skew beyond the leeway window invalidates otherwise-good tokens.
Confirm it’s a 401 and not a 403. If the credentials are valid and it still refuses, you have an authorization (permission) problem, not an authentication one.

When to Escalate

If valid credentials reach the origin and it still returns 401, escalate to whoever owns the auth service — the token issuer, session store, or identity provider may be misconfigured.
If the 401 only appears behind a proxy or CDN, escalate to the platform team to check header-forwarding rules; the Authorization header is being lost in transit.