403 vs 404: Forbidden vs Not Found
403 and 404 can look similar in logs, but they tell clients, crawlers, and API consumers different things.
| Aspect | HTTP 403 — Forbidden | HTTP 404 — Not Found |
|---|---|---|
| Definition | Authentication is not the issue — the authenticated user simply does not have permission to access the resource. Re-authenticating will not help. | 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 | 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. | 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 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). | 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 | Client should not retry without a change in permissions. Users should contact an administrator. Automated clients should surface the error and stop retrying. | 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. Permission checks are per-request. | 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 403 (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 403 expect Forbidden 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 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.
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 403 when the response should communicate forbidden behavior; use 404 when not found is the accurate protocol signal.
A frequent mistake is swapping 403 and 404 for convenience; that causes client retry bugs, incorrect cache signals, and misleading monitoring data.
Use 403 when the correct protocol signal is Forbidden. 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 403 and 404?
403 communicates Forbidden, while 404 communicates Not Found. Choosing the right one keeps clients and intermediaries predictable.
Do 403 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 403 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 403 Forbidden — full guide · HTTP 403 status reference · HTTP 404 Not Found — full guide · HTTP 404 status reference · All comparisons