HTTP 4xx Client Errors Explained — 400, 403, 404, 413, 414 and How to Fix Them

Core Concepts

400 Bad Request — malformed input

The server cannot understand the request. Common causes: malformed JSON with a missing brace, invalid header format, Content-Type mismatch (sending XML to a JSON-only endpoint), or request body larger than a configured limit (though 413 is the correct code for that). Always check the request body first — 99% of 400s are malformed payloads.

403 Forbidden vs 401 Unauthorized

401 'Unauthorized' means 'you didn't prove who you are' — return it when no valid token/credentials are provided. 403 'Forbidden' means 'I know who you are, and you're not allowed to do this' — return it when a valid user tries to access another user's resource, or their role lacks the required permission. Many APIs incorrectly use 403 for missing auth tokens, which should be 401.

413 Payload Too Large & 414 URI Too Long

413 means the request body exceeds your server's max-body-size (e.g., an 11 MB JSON upload to an endpoint that only allows 10 MB). 414 means the URL is too long — most commonly triggered by huge GET query strings (filters with many parameters or deeply-nested query params). Browsers have their own URL length limits (~2,048-100,000 chars depending on the browser). The fix for 414: switch from GET to POST and put the parameters in the request body.

404 Not Found — the most misunderstood code

404 means the resource doesn't exist. It's perfectly normal, not an error — it's the correct response for any URL path that your server doesn't handle. The problem is 'soft 404s': returning a 200 OK with a friendly 'not found' page. Google penalizes soft 404s because they waste crawl budget. Always return the actual 404 status code with your friendly page.

Frequently Asked Questions