HTTP 404 Not Found: Causes, Examples, and Fixes

The HTTP 404 Not Found status code is perhaps the most universally recognized status code in the HTTP standard.

While simple in concept, debugging 404 errors in modern web applications requires understanding routing tables, path normalization, microservice reverse proxies, and HTTP method matching.

Core meaning of HTTP 404

An HTTP 404 Not Found response indicates that the origin server did not find a current representation for the requested target resource, or is unwilling to disclose that one exists.

In other words, the server is running and received your request, but cannot locate anything at the specified URI.

What a 404 response tells you

Receiving an HTTP 404 provides several clear guarantees about your request:

1. The web server is reachable: The host resolved, the port connected, and the HTTP server processed the request.
2. The URI did not match a resource: The server-side router or static file handler could not locate a matching resource or database record for the path.
3. The condition may be temporary or permanent: Unlike status 410 (Gone), 404 does not state whether the resource previously existed or might exist in the future.

GET /v1/users/usr_99999 HTTP/1.1
Host: api.example.test
Accept: application/json

HTTP/1.1 404 Not Found
Date: Thu, 10 Sep 2026 10:00:00 GMT
Content-Type: application/json

{"error": "not_found", "message": "User usr_99999 does not exist."}

GET /v1/user/profile HTTP/1.1
Host: api.example.test
Accept: application/json

HTTP/1.1 404 Not Found
Date: Thu, 10 Sep 2026 10:00:00 GMT
Content-Type: application/json

{"error": "not_found", "message": "Cannot GET /v1/user/profile. Did you mean /v1/users/profile?"}

Common causes of HTTP 404

Typo or Case Mismatch in URI Path

The requested path contains a typo, incorrect pluralization, or uppercase characters on a case-sensitive routing server.

Missing or Deleted Resource Entity

The resource ID in the path parameter does not exist in the database or was permanently deleted.

Unmapped API Version or Prefix

The request omitted an API route prefix (such as /api/v1) or specified an obsolete API version.

Trailing Slash or Method Routing Conflict

The server router requires strict trailing slash conventions or does not map the requested HTTP method at that URI.

URL path, method, and routing checks

When diagnosing a 404 error, systematically inspect the components of the request:

1. URI Path and Base Prefix

Check for missing base paths such as /api, /v1, or /v2. In microservice architectures, an API gateway may strip or require specific path prefixes before routing to upstream services.

2. Case Sensitivity and Typos

While domain names in URLs are case-insensitive, the path portion (/Users vs. /users) is case-sensitive on many operating systems and web frameworks.

3. Trailing Slashes

Some web servers treat /v1/items and /v1/items/ as distinct resources. If strict routing is enabled without redirection, requesting the wrong format can result in a 404.

4. HTTP Method Mismatches

If a router defines a POST handler for /v1/orders but no GET handler, sending a GET request may return 404 (or 405 Method Not Allowed, depending on router design).

HTTP 404 vs. a network failure

It is crucial to distinguish an HTTP 404 response from a network connection failure:

• HTTP 404 Not Found: An active HTTP response generated by a functioning web server. You received valid HTTP response headers and status code 404.
• Network Failure (e.g., DNS error, Connection Refused, Timeout): No HTTP response was received. The client could not establish a TCP or TLS connection with any server.

If your client library throws a network error without an HTTP status code, the issue is transport or DNS connectivity, not an HTTP 404.

HTTP 404 vs. CORS restrictions

When an API returns a 404 response to a cross-origin request made by browser JavaScript, the browser will only allow client code to inspect the 404 response if the server includes Access-Control-Allow-Origin headers.

If those headers are missing on error responses, the browser console will log a CORS error alongside the 404 status. Always check the Network panel to see the actual status code returned by the server.

How to investigate a 404 safely

Follow these steps to isolate the root cause:

1. Inspect the exact request URI: Print or log the full resolved URL including query parameters.
2. Check server route logs: Review server console output or access logs to see which route pattern was evaluated.
3. Verify resource IDs: Query your data store to confirm that the requested entity exists and is active.
4. Test using curl: Run a direct command-line request to bypass browser caching and client-side routers.

What to check before changing code

Before altering client request logic or routing rules, verify:

1. Verify the full request URI: Inspect the exact path, protocol, port, and query parameters to ensure no typographical mistakes or omitted prefixes exist.
2. Check server routing definitions: Confirm that the backend application framework has registered an active handler for the specified path and HTTP method.
3. Verify entity existence in data store: Confirm whether the database record or static file actually exists in the target environment.
4. Distinguish 404 responses from network failures: Ensure that an HTTP response was received from a server rather than encountering a DNS failure or connection timeout.

How to verify the fix

Test the route directly using curl to verify path matching:

curl -i https://api.example.test/v1/users/usr_99999

Confirm whether the server returns 404 with structured error details, or returns 200 OK when querying a known valid ID:

curl -i https://api.example.test/v1/users/usr_12345

Key takeaway

HTTP 404 Not Found means the server was reached successfully but found no resource matching the requested URI path. Check for typos, routing prefixes, trailing slashes, and verify that the target entity exists in the underlying data store before altering client request logic.