401 vs 403: Unauthorized vs Forbidden
401 and 403 can look similar in logs, but they tell clients, crawlers, and API consumers different things.
| Aspect | HTTP 401 — Unauthorized | HTTP 403 — Forbidden |
|---|---|---|
| Definition | Despite the name, 401 is specifically about authentication, not authorization. The server requires the client to authenticate. The response includes a WWW-Authenticate header describing the required authentication scheme. | Authentication is not the issue — the authenticated user simply does not have permission to access the resource. Re-authenticating will not help. |
| Plain-language summary | Authentication is required and has not been provided, or the provided credentials are invalid. The response includes a WWW-Authenticate header describing the required authentication scheme. Despite the name "Unauthorized," this code is specifically about authentication, not authorization. | The client is authenticated but does not have permission to access the resource. The server understood the request and knows who the client is — it simply refuses to authorize this specific action. Re-authenticating will not change the outcome. |
| When to use | Return 401 when the client has not provided credentials or the provided credentials are invalid/expired. Use 403 when the client is authenticated but lacks permission. Include a WWW-Authenticate header specifying the authentication scheme (Bearer, Basic, etc.) so clients know how to authenticate. | Return 403 when the client is authenticated but lacks the required permissions, role, or scope. Use 401 when the issue is authentication (unauthenticated or invalid credentials). Use 404 when you do not want to reveal whether a resource exists at all (security-sensitive resources). |
| Client behavior | Browser: prompts for credentials if WWW-Authenticate: Basic, otherwise shows a login page or error. API client: should prompt re-authentication or refresh the token. Automated clients: should attempt token refresh, then surface the error. Re-authenticating is appropriate and expected. | Client should not retry without a change in permissions. Users should contact an administrator. Automated clients should surface the error and stop retrying. |
| Caching behavior | Not cached. Authentication errors are always re-evaluated. | Not cached. Permission checks are per-request. |
| SEO / crawler impact | Search crawlers interpret 401 (client-errors) for indexation and link equity accordingly. | Search crawlers interpret 403 (client-errors) for indexation and link equity accordingly. |
| API / backend impact | API clients branching on 401 expect Unauthorized semantics. | API clients branching on 403 expect Forbidden semantics. |
| Safe to retry? | Only after fixing the underlying cause | Only after fixing the underlying cause |
Common real-world scenarios
When you see HTTP 401
In API logs, 401s indicate expired tokens, missing Authorization headers, or invalid API keys. Common patterns: a spike in 401s after a token rotation, systematic 401s indicating a service account credential expired, or per-user 401 spikes from a mobile app that is not handling token refresh correctly.
When you see HTTP 403
In logs, 403s indicate RBAC policy mismatches, tenant isolation violations (user A trying to access user B's data), or scope insufficient errors on OAuth tokens. Common production scenarios: a new user missing a required role, an API token created without a needed scope, or an IP allowlist blocking a new service IP.
Decision rule
Use 401 when the response should communicate unauthorized behavior; use 403 when forbidden is the accurate protocol signal.
A frequent mistake is swapping 401 and 403 for convenience; that causes client retry bugs, incorrect cache signals, and misleading monitoring data.
Use 401 when the correct protocol signal is Unauthorized. Use 403 when the correct signal is Forbidden. Returning either code for the wrong reason breaks client expectations, cache behavior, and monitoring accuracy.
FAQ
What is the biggest difference between 401 and 403?
401 communicates Unauthorized, while 403 communicates Forbidden. Choosing the right one keeps clients and intermediaries predictable.
Do 401 and 403 have SEO or caching impact?
Yes. Search engines and caches interpret status classes differently. Use each code according to its semantics to avoid accidental indexing, stale responses, or crawl inefficiency.
Can APIs safely return 401 instead of 403?
Only when it matches contract semantics. API clients often branch logic by exact code, so swapping them can break retries, auth handling, or user-facing errors.
Full guides
HTTP 401 Unauthorized — full guide · HTTP 403 Forbidden — full guide · HTTP 403 status reference · All comparisons · HTTP 401 status reference