Every time your browser loads a page, submits a form, or an API client fetches data, the server responds with an HTTP status code — a three-digit number that tells the client whether the request succeeded, failed, or needs further action. Understanding these codes is fundamental to building reliable web applications, debugging issues, and designing RESTful APIs. This guide covers every status code category, explains the most important codes in detail, and shares practical tips for using them correctly.
HTTP status codes are part of the HTTP response message, sent by the server after processing a client request. They follow a consistent structure: a three-digit number where the first digit defines the response class and the last two digits provide additional specificity.
The five classes are:
Informational codes are rarely seen in everyday browsing but play an important role in specific protocols like WebSockets and HTTP/2.
| Code | Name | Description |
|---|---|---|
| 100 | Continue | The client should continue sending the request body. Used when the request contains an Expect: 100-continue header. |
| 101 | Switching Protocols | The server is switching protocols as requested (e.g., upgrading to WebSocket). |
| 103 | Early Hints | Used to return some response headers before the final HTTP message. Helpful for preloading resources. |
Most developers will rarely interact with 1xx codes directly. The most common scenario is WebSocket handshakes, where the server responds with 101 Switching Protocols to confirm the upgrade from HTTP to WebSocket.
Success codes indicate that the request was processed as expected. Choosing the right 2xx code in your API is important for clear communication with clients.
The most common status code. The request succeeded, and the response body contains the requested resource. Used for successful GET requests, form submissions, and API calls that return data.
The request succeeded and a new resource was created. This is the standard response for POST requests in RESTful APIs. The response should include a Location header pointing to the URI of the newly created resource.
HTTP/1.1 201 Created
Location: /api/users/42
Content-Type: application/json
{"id": 42, "name": "Jane Doe", "email": "jane@example.com"}The request succeeded but there is no content to return. Commonly used for successful DELETE requests and PUT updates where returning the full resource is unnecessary. The response body must be empty.
| Code | Name | When to Use |
|---|---|---|
| 202 | Accepted | The request is accepted for processing but not yet complete (async operations). |
| 206 | Partial Content | The server is delivering only part of the resource (range requests, video streaming). |
| 304 | Not Modified | The resource has not changed since the client's cached version (conditional GET). |
Redirection codes tell the client that the requested resource is available at a different URI. Understanding the distinction between temporary and permanent redirects is critical for SEO and API design.
The resource has been permanently moved to a new URL. Search engines update their index to the new URL, and browsers cache this redirect. Use 301 when you have permanently restructured your site or changed a URL pattern.
SEO impact: 301 redirects pass most of the original page's link equity (PageRank) to the new URL. This is the correct way to handle URL changes without losing search ranking.
The resource is temporarily available at a different URL. Search engines keep the original URL in their index and revisit it later. Use 302 for temporary situations like A/B testing, maintenance pages, or seasonal redirects.
When a client sends a conditional request with headers like If-None-Match (ETag) or If-Modified-Since, and the resource has not changed, the server responds with 304 and no body. This saves bandwidth and speeds up page loads by allowing browsers to use their cached version.
| Code | Name | When to Use |
|---|---|---|
| 307 | Temporary Redirect | Like 302 but preserves the HTTP method (POST stays POST). |
| 308 | Permanent Redirect | Like 301 but preserves the HTTP method. |
Client error codes indicate that the request contains an error or cannot be fulfilled due to something the client did wrong. These are the codes users see most often.
The server cannot process the request due to malformed syntax, invalid parameters, or missing required fields. This is a catch-all for requests that don't match any schema or validation rules.
The request requires authentication and the client has not provided valid credentials. Despite the name, this code means "unauthenticated" — the server knows who you are (or doesn't) and is refusing access. The response should include a WWW-Authenticate header.
The client is authenticated but does not have permission to access the resource. Unlike 401, re-authenticating will not help. Common scenarios include accessing admin pages as a regular user, or requesting a file with restricted permissions.
The requested resource does not exist on the server. This is the most well-known status code on the internet. For APIs, return 404 when a specific resource ID does not exist. For websites, a custom 404 page with navigation links improves user experience.
SEO tip: Too many 404s on your site can signal poor quality to search engines. Monitor your site for broken links and set up proper redirects for moved content. Google Search Console is invaluable for tracking 404 errors.
The requested HTTP method is not supported for the resource. For example, sending a DELETE request to an endpoint that only supports GET and POST. The response should include an Allow header listing the supported methods.
The server timed out waiting for the complete request. This can happen with slow network connections, large file uploads, or client-side issues that prevent the request from being sent in full.
The client has sent too many requests in a given time period. This is the standard response for rate limiting. The response should include a Retry-After header telling the client how long to wait before trying again.
| Code | Name | When to Use |
|---|---|---|
| 406 | Not Acceptable | The server cannot produce a response matching the client's Accept headers. |
| 410 | Gone | The resource is permanently gone (unlike 404, which implies it might exist elsewhere). |
| 413 | Payload Too Large | The request body exceeds the server's size limit. |
| 415 | Unsupported Media Type | The request's Content-Type is not supported. |
| 422 | Unprocessable Entity | The server understands the content type and syntax but cannot process the instructions (WebDAV, common in APIs). |
Server error codes indicate that something went wrong on the server side. The request may have been valid, but the server failed to fulfill it. These should be rare in production and always investigated.
The generic "something went wrong" error. The server encountered an unexpected condition. This could be an unhandled exception, a database connection failure, a configuration error, or any number of server-side issues. In production applications, this should trigger logging and alerting.
The server, acting as a gateway or proxy, received an invalid response from an upstream server. Common in reverse proxy setups (Nginx → Node.js app) where the backend application is down or returning malformed responses.
The server is temporarily unavailable, typically due to overload or maintenance. The response should include a Retry-After header. This is the correct code to return during planned maintenance or when the server is under heavy load.
The server, acting as a gateway or proxy, did not receive a timely response from an upstream server. This often happens when a backend process takes too long to complete — for example, a slow database query or an external API call that hangs.
201 Created for resource creation, not 200 OK.404 when a specific resource is not found, with a clear error message.409 Conflict when the request conflicts with the current state (e.g., duplicate email).422 for validation errors with details about which fields failed.Retry-After header with 429 and 503 responses.301 for permanent URL changes — never use 302 when you mean permanent.404 errors regularly via Google Search Console.410 for content intentionally removed, so search engines deindex it faster.304 handling with ETags or Last-Modified headers to reduce bandwidth.5xx errors are minimized — frequent server errors can lead to ranking penalties.401 Unauthorized means the client has not authenticated — the server doesn't know who is making the request. 403 Forbidden means the client is authenticated but does not have permission for the requested action. In short: 401 = "who are you?" and 403 = "I know who you are, and you can't do that."
Use 201 Created when your POST request creates a new resource. The response should include a Location header with the URL of the new resource. Use 200 OK only if the POST does not create a resource (e.g., triggering a process or submitting a search).
Return 429 Too Many Requests when a client exceeds your rate limit. Include a Retry-After header indicating how many seconds the client should wait. Many APIs also include X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset headers to help clients manage their usage proactively.
A soft 404 is when a page returns a 200 OK status but displays a "not found" message to the user (e.g., a search results page saying "no results found"). Search engines treat this as a regular page and may index it, wasting crawl budget and potentially confusing users. Always return an actual 404 status code for non-existent pages.
Technically, you can use unassigned codes (e.g., 450-499 for application-specific client errors), but this is generally not recommended. Custom codes may conflict with future HTTP standard additions and confuse HTTP clients, proxies, and debugging tools. Stick to standard codes and include additional context in the response body instead.
HTTP status codes are more than just error messages — they are a structured communication protocol between clients and servers. Using the correct status code in your APIs improves developer experience, aids debugging, and ensures your web application behaves predictably. Bookmark this guide as a reference, and use our free HTTP Status Code lookup tool to quickly find any code's meaning, common causes, and recommended fixes.