HTTP Status Codes Reference

What are HTTP Status Codes?

HTTP status codes are three-digit numbers returned by a web server in response to every HTTP request. They tell the client whether the request succeeded, failed, or needs further action. The first digit indicates the category: 1xx informational, 2xx success, 3xx redirect, 4xx client error, 5xx server error.

Status codes are the universal language between clients and servers. Returning the right code matters for API consumers, monitoring systems, caching layers, load balancers, and SEO crawlers — all of which interpret these codes automatically.

Most commonly encountered: 200 OK, 201 Created, 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 422 Unprocessable Entity, 429 Too Many Requests, and 500 Internal Server Error.

1xx — Informational

CodeNameCommon Use
100ContinueClient should send request body
101Switching ProtocolsWebSocket upgrade handshake
102ProcessingServer processing long operation (WebDAV)

2xx — Success

CodeNameJSON API Use
200OKGET, PUT, PATCH success with response body
201CreatedPOST creates a resource — include Location header
202AcceptedAsync job queued — body contains job ID
204No ContentDELETE success — no response body
206Partial ContentRange requests, file streaming

3xx — Redirection

CodeNameUse
301Moved PermanentlyResource permanently relocated — update links
302FoundTemporary redirect (POST becomes GET)
303See OtherPOST/PUT → redirect to result via GET
304Not ModifiedClient cache is fresh — skip response body
307Temporary RedirectSame method preserved on redirect
308Permanent RedirectSame method preserved, permanent

4xx — Client Errors

CodeNameJSON API Use
400Bad RequestInvalid JSON, missing required fields, validation errors
401UnauthorizedMissing or invalid auth token
403ForbiddenValid token but insufficient permissions
404Not FoundResource doesn't exist
405Method Not AllowedPOST to a GET-only endpoint
409ConflictDuplicate resource, version conflict
410GoneResource permanently deleted
413Content Too LargeRequest body exceeds size limit
415Unsupported Media TypeContent-Type is not application/json
422Unprocessable EntityValid JSON but fails business validation
429Too Many RequestsRate limit exceeded — include Retry-After header

5xx — Server Errors

CodeNameJSON API Use
500Internal Server ErrorUnhandled exception — log and return generic message
501Not ImplementedEndpoint defined but not built yet
502Bad GatewayUpstream service returned invalid response
503Service UnavailableServer overloaded or in maintenance
504Gateway TimeoutUpstream service timed out

REST API Status Code Guide

HTTP MethodSuccess CodeNot FoundValidation Error
GET /resources200 OK404 Not Found400 Bad Request
GET /resources/:id200 OK404 Not Found
POST /resources201 Created400 / 422
PUT /resources/:id200 OK404 Not Found400 / 422
PATCH /resources/:id200 OK404 Not Found400 / 422
DELETE /resources/:id204 No Content404 Not Found

Frequently Asked Questions

401 Unauthorized means the request lacks valid authentication — the client is not identified. 403 Forbidden means the client is identified (authenticated) but does not have permission to access the resource. Think of 401 as 'who are you?' and 403 as 'I know who you are, but you cannot do this.'

Use 400 Bad Request when the request is malformed — invalid JSON syntax, missing required headers, or an unparseable body. Use 422 Unprocessable Entity when the JSON is syntactically valid but fails business validation — for example, a date in the past when a future date is required, or an email that already exists.

Both are temporary redirects. The key difference is method preservation: 302 allows the client to change the method (POST to GET) on redirect, while 307 strictly preserves the original method. Use 307 when you redirect a POST and want the client to re-POST to the new location.

204 is used for successful operations that produce no output — typically DELETE or PATCH when there is nothing meaningful to return. Sending a body with a 204 is technically allowed but ignored by most clients.

A 429 Too Many Requests response should include a Retry-After header indicating when the client can try again. You can specify an absolute date or a number of seconds. Also include rate limit headers (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset) so clients can manage their request rate proactively.

Related Tools