HTTP Status Codes — Complete Developer Reference

HTTP status codes are three-digit numbers returned by servers to indicate the outcome of a client's request. Every API call, page load, and resource fetch returns a status code that tells the client what happened — whether the request succeeded, was redirected, requires authentication, or triggered a server error. Understanding these codes is essential for building reliable APIs, debugging integration issues, and configuring monitoring and alerting correctly.

Status codes are organized into five classes based on their first digit. 1xx codes are informational responses indicating the server received the request and is continuing to process it. 2xx codes indicate the request was successfully received, understood, and accepted. 3xx codes indicate the client must take additional action — typically following a redirect — to complete the request. 4xx codes indicate the request contains bad syntax or cannot be fulfilled due to a client-side issue. 5xx codes indicate the server failed to fulfill an apparently valid request due to a server-side issue.

Each status code page below includes the RFC specification reference, correct usage guidance, common misuse warnings, critical headers, real-world API examples from GitHub, Stripe, and AWS, framework-specific code snippets (Express, Django, Spring Boot, FastAPI), a debugging guide, and interactive tools including an HTTP inspector, guided learning lab, and mock endpoint generator. Use the status code comparison tool to understand the differences between similar codes.

1xx — Informational

Interim responses before the final reply. The server acknowledged the request and is continuing to process it.

  • 100 Continue — The server received the request headers; the client should proceed to send the body.
  • 101 Switching Protocols — The server is switching protocols as requested by the client (e.g., upgrading to WebSocket).
  • 102 Processing — The server received and is processing the request, but no response is available yet (WebDAV).
  • 103 Early Hints — The server sends preliminary headers (like Link preload) before the final response.

2xx — Success

The request was received, understood, and accepted. These are the codes you want to see in your API responses.

  • 200 OK — The request succeeded. The meaning depends on the HTTP method: GET returns the resource, POST returns the result of the action.
  • 201 Created — The request succeeded and a new resource was created. The Location header should point to the new resource.
  • 202 Accepted — The request was accepted for processing, but processing is not complete. Used for async operations.
  • 204 No Content — The request succeeded but there is intentionally no response body. Common for PUT, PATCH, and DELETE.
  • 206 Partial Content — The server is returning only part of the resource due to a Range header in the request.
  • 207 Multi-Status — The response body contains status information for multiple independent operations (WebDAV).
  • 208 Already Reported — Members of a DAV binding have already been enumerated in a previous reply (WebDAV).
  • 226 IM Used — The server fulfilled a GET request using instance-manipulations applied to the current instance (delta encoding).

3xx — Redirection

The client must follow a different URI to complete the request. Correct redirect usage is critical for SEO and API stability.

  • 300 Multiple Choices — The request has more than one possible response. The user or user agent should choose one.
  • 301 Moved Permanently — The resource has permanently moved to a new URL. Clients and search engines should update their links.
  • 302 Found — The resource is temporarily at a different URL. Clients should continue using the original URL for future requests.
  • 303 See Other — The response to the request can be found at another URL using GET, regardless of the original method.
  • 304 Not Modified — The resource has not changed since the version specified by If-None-Match or If-Modified-Since headers.
  • 305 Use Proxy — The resource must be accessed through a proxy specified in the Location header (deprecated).
  • 307 Temporary Redirect — The resource is temporarily at a different URL. Unlike 302, the method and body must not be changed.
  • 308 Permanent Redirect — The resource has permanently moved. Unlike 301, the method and body must not be changed.

4xx — Client Error

The request failed due to a client-side issue: invalid input, missing authentication, forbidden access, or a missing resource.

  • 400 Bad Request — The server cannot process the request due to malformed syntax, invalid parameters, or missing required fields.
  • 401 Unauthorized — Authentication is required and has failed or has not been provided. Include WWW-Authenticate header.
  • 403 Forbidden — The server understood the request but refuses to authorize it. Valid credentials don't grant access.
  • 404 Not Found — The requested resource does not exist at this URI. The most widely recognized error code on the web.
  • 405 Method Not Allowed — The HTTP method (GET, POST, etc.) is not supported for this resource. Include Allow header.
  • 406 Not Acceptable — The server cannot produce a response matching the Accept headers sent by the client.
  • 407 Proxy Authentication Required — The client must authenticate with the proxy before the request can proceed.
  • 408 Request Timeout — The server timed out waiting for the client to send the complete request.
  • 409 Conflict — The request conflicts with the current state of the resource (e.g., concurrent edit, duplicate key).
  • 410 Gone — The resource has been permanently removed and will not return. Unlike 404, this is intentional and permanent.
  • 411 Length Required — The server requires a Content-Length header that the client did not provide.
  • 412 Precondition Failed — A precondition in the request headers (If-Match, If-Unmodified-Since) evaluated to false.
  • 413 Payload Too Large — The request body exceeds the server's size limit. May include Retry-After for temporary limits.
  • 414 URI Too Long — The request URI is longer than the server can interpret, typically from excessive query parameters.
  • 415 Unsupported Media Type — The request Content-Type is not supported by the endpoint (e.g., sending XML to a JSON-only API).
  • 416 Range Not Satisfiable — The Range header value is outside the bounds of the resource (e.g., requesting bytes 1000-2000 of a 500-byte file).
  • 417 Expectation Failed — The server cannot meet the Expect request-header requirement (typically Expect: 100-continue).
  • 418 I'm a teapot — An April Fools' joke from RFC 2324 (HTCPC/1.0). Some servers use it as a playful Easter egg.
  • 421 Misdirected Request — The request was directed at a server that cannot produce a response (wrong TLS certificate or HTTP/2 connection).
  • 422 Unprocessable Entity — The request syntax is valid but the content has semantic errors (e.g., validation failures in a JSON body).
  • 423 Locked — The resource is currently locked and cannot be modified (WebDAV).
  • 424 Failed Dependency — The request failed because it depends on another request that also failed (WebDAV).
  • 425 Too Early — The server refuses to process a request that might be replayed (TLS 0-RTT early data risk).
  • 426 Upgrade Required — The server requires the client to upgrade to a different protocol (e.g., HTTP/2 or TLS).
  • 428 Precondition Required — The server requires conditional headers (If-Match, If-None-Match) to prevent lost updates.
  • 429 Too Many Requests — The client has exceeded a rate limit. Include Retry-After to indicate when to retry.
  • 431 Request Header Fields Too Large — The server refuses to process the request because headers are too large (often due to oversized cookies).
  • 451 Unavailable For Legal Reasons — Access is denied due to legal demands (censorship, court order, GDPR). Named after Fahrenheit 451.

5xx — Server Error

The server failed to fulfill a valid request. These indicate bugs, overload, or upstream dependency failures that need investigation.

  • 500 Internal Server Error — A generic server error when no more specific 5xx code is applicable. Usually indicates a bug.
  • 501 Not Implemented — The server does not recognize the HTTP method or lacks the ability to fulfill the request.
  • 502 Bad Gateway — The server, acting as a gateway or proxy, received an invalid response from an upstream server.
  • 503 Service Unavailable — The server is temporarily unable to handle requests due to maintenance or overload. Include Retry-After.
  • 504 Gateway Timeout — The server, acting as a gateway or proxy, did not receive a timely response from the upstream server.
  • 505 HTTP Version Not Supported — The server does not support the HTTP protocol version used in the request.
  • 506 Variant Also Negotiates — Content negotiation resulted in a circular reference and the server cannot select a representation.
  • 507 Insufficient Storage — The server cannot store the representation needed to complete the request (WebDAV).
  • 508 Loop Detected — The server detected an infinite loop while processing the request with Depth: infinity (WebDAV).
  • 510 Not Extended — The server requires further extensions to the request that the client did not provide.
  • 511 Network Authentication Required — The client must authenticate to gain network access (captive portal, e.g., airport Wi-Fi).

Interactive Tools for Every Status Code

Each status code page includes three interactive tools:

  • HTTP Inspector — Execute a real request that returns the status code and analyze the full HTTP exchange: headers, caching behavior, redirect chains, CORS configuration, and timing.
  • Guided Lab — A step-by-step learning experience that helps you reproduce the status code, understand why it occurs, and learn how to fix or handle it correctly in your applications.
  • Mock Endpoint — Generate a shareable URL that returns the exact status code with customizable headers, body, and response delay. Use it for testing, demos, and integration verification.

All tools work directly in your browser with no signup required. You can also compare any two status codes side by side to understand their differences in semantics, headers, caching, and client behavior.

Frequently Asked Questions

What are HTTP status codes?

HTTP status codes are three-digit numbers returned by a server in response to a client request. They indicate whether the request was successful, redirected, or resulted in an error. Codes are grouped into five classes: 1xx (informational), 2xx (success), 3xx (redirection), 4xx (client error), and 5xx (server error).

How many HTTP status codes are there?

There are approximately 60 officially registered HTTP status codes defined across multiple RFCs. The most commonly used in practice are about 20 codes: 200, 201, 204, 301, 302, 304, 307, 308, 400, 401, 403, 404, 405, 409, 422, 429, 500, 502, 503, and 504.

What is the difference between 4xx and 5xx errors?

4xx status codes indicate client errors — the request was invalid, unauthorized, or malformed, and the client needs to modify the request before retrying. 5xx status codes indicate server errors — the server failed to fulfill a valid request, and the client may retry without changes.

What does HTTP 200 OK mean?

HTTP 200 OK means the server successfully processed the request and is returning the requested content. It is the standard response for successful GET, POST, PUT, and DELETE requests when the server has a body to return.

When should I use 201 vs 200?

Use 201 Created when a POST or PUT request creates a new resource — include a Location header pointing to the new resource. Use 200 OK when the request succeeded but no new resource was created, such as retrieving data or updating an existing resource.