<- All Comparisons

404 Not Found vs 410 Gone: Missing vs Permanent Removal

Learn when to return 404 (missing or temporary absence) versus 410 (intentional permanent removal), including redirect and cache implications.

Last reviewed: February 20, 2026|Editorial standard: source-backed comparison guidance

Quick Decision

-Use 404 when the server has no current representation and permanence is not asserted.
-Use 410 when the server knows the resource is intentionally unavailable and this condition is expected to be permanent.
-If a canonical replacement URI exists, prefer permanent redirect semantics (301 or 308) over returning 410.

Key Differences

-404 communicates unresolved current representation; 410 communicates explicit lifecycle retirement intent.
-404 remediation starts with identifier, scope, and routing validation; 410 remediation starts with deprecation and migration policy checks.
-410 gives clients a stronger signal to remove stale references, while 404 does not assert permanent removal.
-404 and 410 responses are heuristically cacheable unless cache controls indicate otherwise.

When To Use 404 Not Found

-Resource lookup currently fails and permanence is unknown.
-Replication lag or eventual consistency might still make the resource visible later.
-Identifier/path is unresolved and no explicit retirement policy exists for that URI.

When To Use 410 Gone

-Resource or endpoint was intentionally retired with no continued representation at that URI.
-Lifecycle/deprecation policy explicitly marks the mapping as permanently removed.
-You want clients and integrations to stop retrying stale URIs and update references.

Step-by-Step Diagnosis

1Trace lifecycle state for the URI (active, deprecated, deleted, migrated) from authoritative change logs.
2Check whether a stable replacement URI exists and decide between 301/308 redirect versus 410 retirement.
3Validate cache headers so stale 404/410 responses do not outlive intended rollout windows.
4Monitor repeated requests to retired URIs and verify client migration rate after response-policy change.

Common Misclassifications

-Returning 404 for permanently retired resources, which removes explicit lifecycle signaling.
-Returning 410 for transient provisioning delays or temporary replication gaps.
-Emitting 410 while documentation and SDKs still point to the retired URI.

Response Examples

404 when current representation is unresolvedhttp

HTTP/1.1 404 Not Found
Content-Type: application/json

{
  "error": "not_found",
  "message": "No current representation for this URI."
}

410 when URI is intentionally retiredhttp

HTTP/1.1 410 Gone
Content-Type: application/json

{
  "error": "gone",
  "message": "This endpoint was permanently removed."
}

Pro Tip

-Treat 410 as an API lifecycle event: publish deprecation timelines, replacement guidance, and request-volume telemetry for retired URIs.

Frequently Asked Questions

When should I return 410 instead of 404?

Return 410 when permanent retirement is intentional and known by the server. Use 404 when current representation is unavailable but permanence is not asserted.

For retired endpoints, should I return 410 or 301/308?

Use 301 or 308 when there is a canonical replacement URI. Use 410 when no replacement exists and the old URI is intentionally retired.

Are 404 and 410 cacheable by default?

They can be heuristically cacheable unless explicit cache controls override that behavior, so set caching headers intentionally during migrations and retirements.

404 Not Found

Open detail page

410 Gone

Open detail page

Official References

Related Articles

403 Forbidden vs 404 Not Found: When to Hide Resources

Use 403 for explicit access denial, or 404 to conceal resource existence when security policy requires reducing endpoint and object enumeration risk.

401 Unauthorized vs 403 Forbidden: Auth vs Access Denied

Fix 401 Unauthorized vs 403 Forbidden by separating authentication failures from authorization denials, then apply the right login or permission fix fast.

404 Not Found vs 410 Gone: Missing vs Permanent Removal | HTTP