404 vs 500: HTTP Status Codes

An HTTP status code tells the client how the server handled a request. 404 Not Found means no matching resource (or you are not allowed to know it exists). 500 Internal Server Error means the server hit an unexpected failure while processing. Confusing them wastes hours — caching a 404 will not fix a crashing app.

Just need one code? Jump straight to HTTP status code 404 or HTTP status code 500 — this post is for telling the two apart.

404 vs 500 at a glance

Code	Class	Typical cause
404	4xx client	Wrong URL, deleted page, bad route
403	4xx client	Authenticated but forbidden
500	5xx server	Unhandled exception, misconfig
502/503	5xx server	Bad gateway / unavailable upstream

APIs sometimes return 404 for “ID not in database” and 400 for validation errors — check your API’s conventions.

Debugging checklist

1. Reproduce with curl or DevTools; note method and path.
2. For 404 — verify routing, trailing slashes, deploy output, CDN rules.
3. For 500 — read server logs, recent deploys, dependency outages.
4. Confirm you are not caching an old error response.

Telling them apart from the response alone

You often only have the status line and a browser tab. That is usually enough:

Signal	Points to 404	Points to 500
Other pages on the site	Work fine	Often also failing
Retrying the same URL	Same result every time	May succeed intermittently
Changing the URL slightly	Different result	Same failure
Server logs	Usually nothing, or a routing miss	Stack trace at the moment of the request
Who can fix it	Often the caller (wrong URL)	Only the server owner

That last row is the practical one. A 404 is frequently something you can correct from the client side; a 500 never is. Retrying a 500 harder does not help, and hammering it can make recovery slower for everyone.

The ones that get mistaken for these two

• 401 vs 403 vs 404. 401 means “not authenticated — log in.” 403 means “authenticated, but not allowed.” Some APIs deliberately return 404 instead of 403 so an attacker cannot confirm that a private resource exists. A 404 on something you believe exists may actually be a permissions decision.
• 502 and 504 are not 500. All three are 5xx, but 500 is the application failing, 502 means a proxy got an invalid response from upstream, and 504 means upstream did not answer in time. That distinction points at different infrastructure — app code versus the hop between proxy and origin.
• 503 means “come back later” and often carries a Retry-After header. It is the one 5xx that explicitly invites a retry.
• A 200 with an error inside. Plenty of APIs return 200 OK with {"error": ...} in the body. Status-code-only error handling silently treats those as success — check the body shape for APIs you do not control.

Before you start debugging

1. Reproduce with curl -i so you see the real status line and headers, not a framework’s error page.
2. Note the exact method and path — a 404 on POST /orders when GET /orders works is a 405 in disguise.
3. Check whether a CDN or proxy sits in front. It can serve a cached 404 for a path the origin now handles, or turn an origin timeout into a 502.
4. For 5xx, go to the server logs at the timestamp of the request. Client-side changes cannot fix a genuine 500, so time spent tweaking the payload is time lost.

Reference on TryDevSnip

Browse TryDevSnip HTTP Status Codes or jump to HTTP 404 and HTTP 500 explainers. Use them as a quick glossary while debugging.

Privacy one-liner: the reference pages are static and run in your browser; not uploaded to our servers for processing.

Related: URL Encode when bad encoding produces odd paths that 404.

FAQ

Should APIs use 404 or 400 for missing IDs?

Both exist in the wild. 404 is common for “resource not found”; document your choice.

Is 500 ever the client’s fault?

Usually not — but bad input that trips an unhandled bug surfaces as 500. Fix the server to return 4xx for expected validation failures.

What about 204 and 201?

Success codes: 201 Created, 204 No Content. Different class from errors.

Why do I see 404 from a CDN for a working origin?

CDN path rules, case sensitivity, or the edge never fetched the new object after deploy.