HTTP Status Codes

The request was received and is being processed; the client can keep going.

Informational responses are transitional. They are sent before the final response while the server is still working, so the client knows the request arrived and can keep going. 100 Continue works together with the Expect header: a client can ask whether the server will accept a large body before uploading it. 103 Early Hints is newer and lets the server send preliminary Link headers so the browser can preload critical assets before the main body arrives. The boundary to remember is that a 1xx code never ends the exchange. This is why they appear in raw network traces but seldom in application code; fetch() and XMLHttpRequest surface only the final response, which is the behavior MDN documents for status handling.

The request was received, understood and accepted.

Success responses share one property: the request was understood and accepted. The specific code records what kind of success happened. 200 OK returns the requested representation, 201 Created reports a new resource and should point to it with a Location header, 202 Accepted defers the real work, 204 No Content succeeds without a body and is the natural answer for DELETE, and 206 Partial Content returns only the byte range requested through a Range header and adds a Content-Range header for the full size. Picking the narrowest code matters. A 201 tells the client which resource to load next, a 204 keeps the current view intact, and a 206 keeps a resumable download alive, so flattening everything into 200 throws that information away.

The client must take further action, usually by following a new location.

Redirection tells the client to look elsewhere, usually at the URI carried by the Location header, and the exact code controls what happens to the request method. 301 Moved Permanently and 308 Permanent Redirect mark a lasting move, while 302 Found and 307 Temporary Redirect cover a temporary one. The subtle part is method preservation: RFC 9110 notes that many historical clients rewrite the method of a 301 or 302 response to GET, which is exactly why 307 and 308 were defined to keep the method and body intact. 303 See Other explicitly tells the client to fetch the result with GET, and 304 Not Modified is the caching case: it carries no body and tells the client its stored copy is still valid.

The request is malformed, unauthorized or references a missing resource.

Client errors say the request itself is the problem. 400 Bad Request covers malformed syntax, while 422 Unprocessable Content, standardized in RFC 9110, means the message is well formed but fails the application's business rules. 401 Unauthorized asks for authentication and carries a WWW-Authenticate header, whereas 403 Forbidden means the server knows who you are but refuses the action. 404 Not Found is also the privacy-friendly answer, because it avoids confirming whether a resource exists, and 410 Gone goes further by stating the resource used to exist. 429 Too Many Requests should send Retry-After so clients know when to back off, and 405 Method Not Allowed should list the allowed methods in an Allow header. A common source of confusion is mixing 400 with 422: if the JSON is syntactically valid but the values fail business rules, the correct signal is 422, not 400. Just as important, a 4xx code should never leak stack traces or database error text, since these responses may be cached or forwarded.

The server failed to fulfill a request that otherwise appeared valid.

Server errors announce that the failure happened on the serving side, no matter what the client sent. 500 Internal Server Error is the catch-all for unhandled exceptions, 501 Not Implemented means the server does not support the requested functionality, and 505 HTTP Version Not Supported, defined in RFC 9112, rejects a protocol version the server cannot speak. The gateway codes describe the position of the failure: 502 Bad Gateway means a proxy received an invalid response from an upstream server, 503 Service Unavailable means the server is temporarily overloaded or down for maintenance and should pair with Retry-After, and 504 Gateway Timeout means the upstream never answered in time. Collapsing every failure into 500 hides all of that diagnostic value.