HTTP Status Codes Explained: 200, 301, 404, 500 and What They Mean

Every HTTP response carries a three-digit status code that tells the client exactly what happened. The codes fall into five classes, each with a clear semantic meaning. Once you understand the structure, you can decode any code — even ones you've never seen before.

The Five Classes

HTTP status codes are grouped by their first digit. This is not arbitrary: the groupings have consistent semantics that let you reason about any code even without memorising it.

• 1xx — Informational: The request was received and is being processed. Rarely seen in application logic.
• 2xx — Success: The request was received, understood, and accepted.
• 3xx — Redirection: The client must take additional action to complete the request.
• 4xx — Client Error: The request contains bad syntax or cannot be fulfilled. The client is at fault.
• 5xx — Server Error: The server failed to fulfil a valid request. The server is at fault.

2xx: Success Codes

200 OK

The standard success response. The request succeeded and the response body contains the result. This is the correct response for GET requests that return data.

201 Created

The request succeeded and a new resource was created. Use this for POST requests that create resources. Best practice: include a Location header pointing to the newly created resource's URL.

204 No Content

The request succeeded but there is no response body. Use this for DELETE requests and for PUT/PATCH requests where you don't need to return the updated resource. Do not return 200 with an empty body — that is technically incorrect.

206 Partial Content

The server is delivering part of the resource in response to a range request. Common in video streaming, where clients request specific byte ranges to support seeking.

3xx: Redirection Codes

301 Moved Permanently

The resource has permanently moved to a new URL (given in the Location header). Browsers and search engines cache this redirect indefinitely. Use for permanent URL changes, like when you migrate a website or rename a page.

302 Found (Temporary Redirect)

The resource is temporarily at a different URL. Browsers follow the redirect but don't cache it. Often misused — many frameworks return 302 when they should return 301. Note that per the HTTP spec, 302 preserves the original HTTP method, but most browsers change POST to GET on a 302, which led to the creation of 303 and 307.

304 Not Modified

The client's cached version is still current. Returned when the server compares the client's If-Modified-Since or ETag against the current resource. The response body is empty — the client should use its cached copy. This is how HTTP caching works efficiently.

4xx: Client Error Codes

400 Bad Request

The server cannot process the request due to invalid syntax, malformed JSON, missing required fields, or other client-side issues. Include a descriptive error body explaining what is wrong — "400 Bad Request" alone is not helpful to an API consumer.

401 Unauthorized

Despite the name, this means unauthenticated. The client has not provided valid credentials. The response should include a WWW-Authenticate header indicating how to authenticate. Use 401 when the request needs authentication that was not provided or was invalid (expired token, wrong password).

403 Forbidden

The client is authenticated but not authorised to access this resource. Unlike 401, the server knows who you are — it just won't let you do what you're trying to do. Use 403 when a logged-in user tries to access admin resources, for example.

404 Not Found

The most famous code. The resource does not exist at this URL. Can also be used intentionally to hide the existence of resources the client should not know about (instead of returning 403, which reveals that the resource exists).

405 Method Not Allowed

The HTTP method used is not supported for this endpoint. For example, sending a DELETE request to a read-only endpoint. The response must include an Allow header listing the permitted methods.

409 Conflict

The request conflicts with the current state of the resource. Common uses: trying to create a resource that already exists (duplicate username), or a concurrent edit conflict.

422 Unprocessable Entity

The syntax is valid but the content is semantically incorrect. Use this for validation failures — the JSON is well-formed, but a field value fails business rules (e.g., a negative price, an invalid date range). Many REST API designers prefer 422 over 400 for validation errors because it is more semantically precise.

429 Too Many Requests

The client has exceeded the rate limit. Best practice: include a Retry-After header indicating how long to wait before retrying, and a X-RateLimit-Remaining header showing the current quota.

5xx: Server Error Codes

500 Internal Server Error

A generic catch-all for server-side failures. Something went wrong and the server doesn't know specifically what. Log the full error server-side but never expose stack traces or internal error messages to clients — they are a security risk.

502 Bad Gateway

A server acting as a gateway (like a load balancer or reverse proxy) received an invalid response from an upstream server. Common when a backend service is down or crashing.

503 Service Unavailable

The server is temporarily unable to handle the request, typically due to overload or maintenance. Include a Retry-After header when the downtime is expected to be short.

504 Gateway Timeout

The gateway server did not receive a timely response from an upstream server. Distinct from 503 — the upstream is not responding at all, rather than being unavailable.

Common API Design Mistakes

• Using 200 for everything and putting error information in the body — this breaks HTTP semantics and makes clients harder to write
• Confusing 401 and 403 — if the user is logged in and denied, use 403; if not logged in, use 401
• Using 404 for validation errors — a missing required field is a 400 or 422, not a 404
• Returning 500 for client errors — if the client sent bad data, use a 4xx code, not 5xx
• Not including error descriptions in 4xx responses — always explain what went wrong and how to fix it