HTTPAPIsWeb

HTTP Status Codes: The Complete Developer Reference

April 8, 2026 · 7 min read

HTTP status codes are three-digit numbers that a server returns to tell the client what happened to their request. Understanding them is essential for building and debugging APIs. Here's every code you're likely to encounter, explained plainly.

1xx — Informational

Code	Name	Meaning
100	Continue	Server received the request headers; client should proceed to send the body.
101	Switching Protocols	Server is switching to the protocol requested (e.g. WebSockets).
102	Processing	Server has received the request but has not yet completed it (WebDAV).

2xx — Success

Code	Name	Meaning
200	OK	Request succeeded. Standard response for GET, POST, PUT.
201	Created	Resource was created. Typically returned after a successful POST.
202	Accepted	Request accepted for processing but not yet complete (async operations).
204	No Content	Request succeeded but there's no response body. Common for DELETE.
206	Partial Content	Server is delivering part of a resource (range requests, file downloads).

3xx — Redirection

Code	Name	Meaning
301	Moved Permanently	Resource has permanently moved to a new URL. Browsers and bots update their links.
302	Found	Temporary redirect. The resource is currently at a different URL.
303	See Other	Response to the request can be found at another URI using GET (after POST).
304	Not Modified	Resource hasn't changed since last request. Client should use its cached version.
307	Temporary Redirect	Like 302 but the method must not change (POST stays POST).
308	Permanent Redirect	Like 301 but the method must not change.

4xx — Client Errors

Code	Name	Meaning
400	Bad Request	Request is malformed — missing fields, invalid JSON, wrong content type.
401	Unauthorized	Authentication required (despite the name). No valid credentials provided.
403	Forbidden	Authenticated but not permitted. You're logged in but don't have access.
404	Not Found	Resource doesn't exist at this URL.
405	Method Not Allowed	HTTP method is not supported for this endpoint (e.g. DELETE on a read-only resource).
408	Request Timeout	Server timed out waiting for the client to send the full request.
409	Conflict	State conflict — e.g. creating a resource that already exists.
410	Gone	Resource permanently deleted. Stronger than 404 — it existed but is gone for good.
413	Payload Too Large	Request body exceeds the server's size limit.
415	Unsupported Media Type	Content-Type header is not supported (e.g. sending XML to a JSON-only endpoint).
422	Unprocessable Entity	Request is syntactically valid but semantically wrong (validation errors).
429	Too Many Requests	Rate limit exceeded. Usually includes a Retry-After header.

5xx — Server Errors

Code	Name	Meaning
500	Internal Server Error	Generic server-side failure. Something crashed unexpectedly.
501	Not Implemented	Server doesn't support the requested functionality.
502	Bad Gateway	Server acting as a gateway got an invalid response from an upstream server.
503	Service Unavailable	Server is down or overloaded. Often temporary. Check Retry-After header.
504	Gateway Timeout	Upstream server didn't respond in time.
507	Insufficient Storage	Server has no space to store the representation (WebDAV).

The Most Common Mistakes

401 vs 403 — Use 401 when the user isn't logged in. Use 403 when they're logged in but not allowed. Mixing these up leaks information about which resources exist.

200 vs 201 — Return 201 after creating a resource, not 200. Include a Location header pointing to the new resource.

400 vs 422 — Use 400 for malformed requests (bad JSON, missing required fields). Use 422 for valid requests with semantic errors (email already taken, end date before start date).

Don't use 200 for errors — Wrapping errors in a 200 response body breaks every client, monitoring tool, and load balancer that reads status codes.