401 vs 404: Unauthorized vs Not Found
401 and 404 can look similar in logs, but they tell clients, crawlers, and API consumers different things.
| Aspect | HTTP 401 — Unauthorized | HTTP 404 — Not Found |
|---|---|---|
| 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. | The server found no resource matching the requested URL. It does not indicate whether the resource ever existed or whether it might exist in the future. |
| 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 server cannot find any resource at the requested URL. The URL may have never existed, the resource may have been deleted, or the URL may be typed incorrectly. The server makes no guarantee about whether the resource might exist in the future. |
| 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 404 when no resource exists at the requested URL. Use 410 Gone when the resource existed and has been intentionally, permanently removed (helps crawlers delist faster). Use 403 when the resource exists but access is denied. Avoid soft 404s (returning 200 with "page not found" content) — search engines treat them as indexed pages. |
| 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. | No automatic retry. Browser displays the 404 error page. Crawlers record the URL as not found and typically delist it after repeated 404 responses. API clients should surface the error and not retry. |
| Caching behavior | Not cached. Authentication errors are always re-evaluated. | May be cached if the server includes a Cache-Control header, but this is rarely appropriate. Most servers do not cache 404s. CDNs may cache 404s if Cache-Control: max-age is present — be careful with CDN 404 caching for dynamic routes. |
| SEO / crawler impact | Search crawlers interpret 401 (client-errors) for indexation and link equity accordingly. | Search crawlers interpret 404 (client-errors) for indexation and link equity accordingly. |
| API / backend impact | API clients branching on 401 expect Unauthorized semantics. | API clients branching on 404 expect Not Found 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 404
A baseline of 404s is normal (bad links from external sites, typos, old URLs). Alert on: sudden spikes in 404s (deployment broke routes), 404s on URLs that were recently 200 (routing regression), and systematic 404s on specific URL patterns (broken redirect or routing rule).
Decision rule
Use 401 when the response should communicate unauthorized behavior; use 404 when not found is the accurate protocol signal.
A frequent mistake is swapping 401 and 404 for convenience; that causes client retry bugs, incorrect cache signals, and misleading monitoring data.
Use 401 when the correct protocol signal is Unauthorized. Use 404 when the correct signal is Not Found. Returning either code for the wrong reason breaks client expectations, cache behavior, and monitoring accuracy.
FAQ
What is the biggest difference between 401 and 404?
401 communicates Unauthorized, while 404 communicates Not Found. Choosing the right one keeps clients and intermediaries predictable.
Do 401 and 404 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 404?
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 404 Not Found — full guide · HTTP 404 status reference · All comparisons · HTTP 401 status reference