Free HTTP Status Code Cheat Sheet

This informational response usually appears when a client sends an `Expect: 100-continue` header before uploading a large payload.

A 101 response confirms the connection is moving from HTTP to another protocol such as WebSocket.

This WebDAV status tells the client the request is valid but the final response is not ready yet.

A 103 response can expose headers like `Link: rel=preload` so the client starts fetching critical assets earlier.

This is the standard success response for most REST API reads, updates, and actions that return content.

A 201 response is the clearest success code for resource creation and often includes the new resource or a `Location` header.

This is useful for async APIs where the server queues work and finishes it later.

A 204 response is common for deletes, toggles, and idempotent updates where an empty body is intentional.

This status supports resumable downloads and streaming by returning the requested byte range instead of the full payload.

A 301 redirect tells clients and search engines to update bookmarks, caches, and links to the new location.

Many legacy systems use 302 for temporary redirects, although 307 is safer when the HTTP method must be preserved.

A 304 response appears when conditional request headers such as `If-None-Match` or `If-Modified-Since` match the current resource state.

A 307 redirect is the safer modern choice for temporary API redirects because it preserves the original HTTP verb and body.

A 308 combines the permanence of 301 with method preservation, which makes it useful for API route migrations.

A 400 response means the client sent invalid syntax, missing required fields, or an otherwise unusable request.

Despite the name, 401 is about authentication failure, not permission failure.

A 403 response means the server understood the request and credentials, but policy or permissions block the action.

A 404 is the standard response when the client asks for an unknown endpoint or a missing record.

A 405 response commonly appears when a client sends POST to a GET-only endpoint or DELETE to a read-only route.

A 408 response usually means the client was too slow sending headers or the request body.

A 409 response fits concurrency and uniqueness problems where the request is valid but cannot be applied as-is.

A 410 response is more explicit than 404 when a resource or endpoint has been permanently removed.

This response appears when headers like `If-Match` or `If-Unmodified-Since` do not match the server state.

A 415 response means the `Content-Type` is wrong or the server cannot parse that media type for the endpoint.

A 422 response is useful when the payload is syntactically correct JSON but business validation still fails.

A 429 response protects an API when a caller exceeds request, token, or concurrency quotas.

This often happens when cookies, custom headers, or auth metadata grow beyond configured size limits.

A 451 response indicates the server is intentionally withholding the resource because of legal demands or jurisdiction-based restrictions.

A 500 response is the general fallback for unhandled exceptions, broken assumptions, and unexpected runtime failures.

A 501 response means the server does not recognize or cannot fulfill the method or capability the client requested.

This usually points to issues between services rather than a direct client mistake.

A 503 response is appropriate for planned maintenance, overload protection, or short-lived dependency outages.

A 504 response signals that an intermediary waited too long for a backend dependency or origin service.

This WebDAV-origin status can also surface in storage-heavy APIs when disk or object storage limits are exhausted.

This status is rare in general REST APIs but can appear in recursive graph, sync, or WebDAV operations.

This status is typically generated by a proxy or captive portal rather than the API application itself.