HTTP 400 Series Codes: The Client Error Guide

Someone fills out a form, hits submit, and instead of the page they wanted they get an error. Login prompt. Missing page. Request that just refuses to go through. Feels like the site broke. Usually it didn’t, the server’s fine, it’s the request that had the problem.

A blank field here, an expired session there, a page that got deleted last month, access nobody ever granted. That’s what lands you in the http 400 range.

Fast version of the bigger picture: HTTP codes come in five blocks. 100s = still working on it. 200s = it worked. 300s = go look somewhere else. 500s = server broke. 400s = server got the request, understood it, and still couldn’t do anything with it. That last group is what this is about.

Default catch-all error, honestly. Broken JSON. A query param that makes no sense. Empty field that was supposed to be filled in. The server just can’t parse it so it stops right there, not broken, just no reasonable guess to make.

HTTP/1.1 400 Bad Request
Content-Type: application/json

{
“message”: “Invalid request format”
}

Name throws people off. Doesn’t mean denied. means the server has no clue who’s even asking. No token, session timed out, never logged in to begin with. Fix the credentials, request goes through.

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer

This one’s basically unused. Set aside ages ago for online payments that never actually became a real standard, so sites just built their own checkout flows instead. A handful of subscription APIs use it now, hit your quota, next request comes back 402 instead of running.

HTTP/1.1 402 Payment Required

Constantly mixed up with 401 but they’re not the same. 401, server doesn’t know who’s asking. 403, knows exactly who, still says no. Regular user opens an admin page, no admin access, request’s valid, page exists, identity’s confirmed, permission just isn’t there. Logging back in changes nothing here.

HTTP/1.1 403 Forbidden

The famous one. Server looked, nothing there, deleted, typo, moved with no redirect set up. Not necessarily gone forever though, could show up again. If it’s actually permanent, 410’s the better code for it (down below). Also: a pile of unfixed 404s does hurt SEO over time, more so on sites with a lot of internal links.

HTTP/1.1 404 Not Found

Not about what’s inside the request, about how long it took to show up. Slow connection, upload that stalls, client that just stops mid-send. Server waits a bit, gives up, closes it. Nothing necessarily wrong, just ran out the clock.

HTTP/1.1 408 Request Timeout

Two updates hitting the same thing at the same time and they don’t line up. Username already taken, old data overwriting something newer. Same logic as a Git merge conflict, different layer of the stack.

HTTP/1.1 409 Conflict

Close to 404 but more final about it. 404 leaves the door open. 410 shuts it, this exists, it’s not coming back. Search engines actually care about the difference, since 410 tells them to just drop it from the index instead of checking again later. Shows up mostly with discontinued stuff or old docs that got retired for good.

HTTP/1.1 410 Gone

Request comes in a format the endpoint doesn’t deal with. XML to a JSON-only API. GIF where only JPEGs are allowed. Content’s probably fine, format isn’t.

HTTP/1.1 415 Unsupported Media Type
Content-Type: application/json

Gets confused with 400 a lot. 400, couldn’t even parse it. 422, parsed it fine, data just didn’t pass. Registration form, everything filled out right, email’s valid, password’s strong, still fails because the username’s taken already. Nothing wrong with how the request’s built, the data just doesn’t clear the bar. Laravel, Rails, most REST setups lean on this constantly.

HTTP/1.1 422 Unprocessable Content

Rate limiting, plain and simple. Too much too fast, server starts blocking till things cool off. Comes up a lot with scraping, testing, and repeated login attempts. Good APIs throw a Retry-After header in so there’s no guessing on the wait time.

HTTP/1.1 429 Too Many Requests
Retry-After: 60