Every time you open a web page, submit a form, or call a REST API, your browser and the server engage in a silent conversation. The HTTP status code is the server's way of telling the client what happened to the request. Was it successful? Was the resource missing? Is the server overwhelmed? These three-digit numbers are the universal language of the web, and understanding them is non-negotiable for anyone building or debugging web applications.
Whether you are troubleshooting a broken API integration, optimizing your site for search engines, or designing a new RESTful service, a solid grasp of the full http status code list saves hours of guesswork. We built our free HTTP Status Code Lookup tool to make this reference instantly accessible. Type any code and get a plain-English explanation, common causes, and actionable fixes. This article expands that into a comprehensive guide covering every category from 1xx through 5xx.
What Are HTTP Status Codes?
HTTP status codes are standardized response codes defined by the Internet Engineering Task Force (IETF) in a series of Request for Comments (RFC) documents. The most foundational is RFC 9110, which defines the semantics of HTTP. Each code is a three-digit integer where the first digit indicates the class of response, and the remaining two digits provide specificity within that class.
When a client (typically a browser or an API consumer) sends an HTTP request to a server, the server replies with a status line that includes the HTTP version, the status code, and a reason phrase. For example:
HTTP/1.1 404 Not FoundThe reason phrase (Not Found) is human-readable but non-binding. The actual behavior is determined by the numeric code. Modern APIs and CDNs often return custom reason phrases or omit them entirely, but the code itself must conform to the RFC semantics to ensure interoperability.
Status codes are not errors by default. A 4xx code indicates a client-side problem, while a 5xx code indicates a server-side problem. A 3xx code is not a failure either; it is an instruction to look elsewhere. Understanding these distinctions is critical for debugging, monitoring, and building resilient systems.
The Five Categories of HTTP Status Codes
The http status codes are grouped into five classes. Memorizing these five buckets gives you a mental model for interpreting any code you encounter in the wild:
| Category | Range | Meaning | Common Example |
|---|---|---|---|
| Informational | 1xx | The server has received the request and is continuing the process | 100 Continue |
| Success | 2xx | The request was successfully received, understood, and accepted | 200 OK |
| Redirection | 3xx | Further action must be taken to complete the request | 301 Moved Permanently |
| Client Error | 4xx | The request contains bad syntax or cannot be fulfilled | 404 Not Found |
| Server Error | 5xx | The server failed to fulfill an apparently valid request | 500 Internal Server Error |
Think of this table as your http status codes cheat sheet. When you see an unfamiliar code, the first digit immediately tells you who is responsible and what kind of action is required.
1xx Informational Responses
The 1xx class is rarely seen in day-to-day web development because these codes are part of the underlying transport negotiation rather than the final response. They indicate that the server has received the request headers and the client should proceed.
- 100 Continue — The server has received the request headers and the client should send the request body. This is used when the client sends
Expect: 100-continueto avoid uploading large payloads if the server will reject them. - 101 Switching Protocols — The server agrees to switch protocols as requested by the client. The most common use case is upgrading from HTTP to WebSocket.
- 102 Processing — The server has received and is processing the request, but no response is available yet. Defined in WebDAV (RFC 2518) to prevent client timeouts during long operations.
- 103 Early Hints — The server returns some response headers before the final response, allowing the client to start preloading resources. Supported by Chrome and used to optimize Largest Contentful Paint (LCP).
In practice, you will not log or alert on 1xx codes, but knowing they exist helps when debugging WebSocket connections or optimizing page load performance with Early Hints.
2xx Success Responses
The 2xx class means the request succeeded. However, "success" can mean different things depending on the HTTP method and the application context. Here is the complete list of common 2xx codes:
- 200 OK — The request succeeded. The meaning depends on the method: GET returns a representation; POST returns the result of the action; TRACE returns the request message.
- 201 Created — The request succeeded and a new resource was created. Typically returned from POST or PUT.
- 202 Accepted — The request has been accepted for processing but the processing is not complete. Used for asynchronous operations.
- 204 No Content — The server successfully processed the request but is not returning any content. Common for DELETE success.
- 205 Reset Content — Like 204, but the client should reset the document view. Rarely used.
- 206 Partial Content — The server is delivering only part of the resource due to a range header. Used for resumable downloads and video streaming.
- 207 Multi-Status — A WebDAV response that provides status for multiple independent operations.
- 208 Already Reported — Used inside a WebDAV 207 response to avoid enumerating the same collection twice.
- 226 IM Used — The server has fulfilled a GET request with instance manipulations applied to the current instance.
200 OK
200 is the most common status code on the web. It simply means the request was successful. For a GET request, the response body contains the requested resource. For a POST request, the body may contain the result of the operation or a representation of the newly created resource. Because 200 is a catch-all success code, REST API designers sometimes overuse it. Returning 200 for a POST that actually created a resource misses an opportunity to communicate more precisely with 201 Created.
201 Created
201 tells the client that a new resource was created as a result of the request. The response should include a Location header pointing to the newly created resource. In REST API design, 201 is the correct response for a successful POST that adds a record to a database, uploads a file, or submits an order. Using 201 instead of 200 makes your API more predictable and easier to consume programmatically.
204 No Content
204 indicates success with an empty response body. It is the standard response for a DELETE request that removed a resource, or a PUT request that updated a resource where the client does not need the updated representation. Returning 204 instead of 200 with an empty JSON object () is more semantically correct and saves a few bytes on the wire. If the client needs the updated resource, return 200 with the representation instead.
3xx Redirection Messages
The 3xx class tells the client that the requested resource is available at a different location or that a different action is required. These codes are essential for SEO, URL migrations, and load balancing. Here are the common 3xx codes:
- 300 Multiple Choices — The request has more than one possible response. The client should choose one. Rarely used in practice.
- 301 Moved Permanently — The resource has been permanently moved to a new URL. Future requests should use the new URL.
- 302 Found — The resource is temporarily at a different URL. The client should continue using the original URL for future requests.
- 303 See Other — The response to the request can be found at another URL, and the client should use GET to retrieve it. Used after POST to redirect to a confirmation page.
- 304 Not Modified — The resource has not changed since the version specified in the
If-Modified-SinceorIf-None-Matchheaders. The client can use its cached copy. - 307 Temporary Redirect — Similar to 302, but the client must not change the request method when following the redirect.
- 308 Permanent Redirect — Similar to 301, but the client must not change the request method when following the redirect.
301 Moved Permanently
301 is the correct code when you permanently change a URL. Search engines transfer most of the ranking signals from the old URL to the new one. Browsers cache 301 redirects aggressively, which improves performance for repeat visits. If you later revert the change, some clients may continue to hit the new URL due to cache behavior, so only use 301 when you are certain the move is permanent.
302 Found
302 indicates a temporary redirect. Historically, some clients treated 302 like 303 and changed POST to GET on redirect, which caused data loss. Because of this ambiguity, 302 is less preferred for APIs. It remains common in traditional web applications for login redirects and A/B testing.
307 Temporary Redirect
307 was introduced in HTTP/1.1 to fix the ambiguity of 302. With 307, the client must repeat the request to the new URL using the same method. If you POST to a URL and receive 307, you POST again to the new location. This makes 307 the safer choice for temporary redirects in REST APIs and form submissions.
308 Permanent Redirect
308 is the permanent equivalent of 307. It behaves like 301 but guarantees that the request method and body are preserved. If you are building a modern API or performing a permanent URL migration where POST data must survive the redirect, 308 is the most precise code available.
301 vs 302 vs 307 vs 308 Comparison
| Code | Permanence | Method Preservation | Best Use Case |
|---|---|---|---|
| 301 | Permanent | May change to GET (legacy behavior) | SEO-friendly permanent URL moves |
| 302 | Temporary | May change to GET (legacy behavior) | Legacy web apps, login redirects |
| 307 | Temporary | Must preserve method | API temporary redirects, form handling |
| 308 | Permanent | Must preserve method | Modern permanent redirects with POST safety |
When debating 301 vs 302, the key question is permanence. If the old URL will never come back, use 301 or 308. If the redirect is an experiment or maintenance window, use 302 or 307. For APIs, prefer 307 and 308 to avoid method-changing surprises.
4xx Client Error Responses
The 4xx class indicates that the client made an error. The server cannot or will not fulfill the request because of something the client did wrong. These are the codes you will encounter most often during development. Here is the list of common 4xx codes:
- 400 Bad Request — The server cannot process the request due to client error (malformed syntax, invalid parameters).
- 401 Unauthorized — Authentication is required and has failed or not been provided.
- 402 Payment Required — Reserved for future use. Occasionally used for rate limiting or quota exceeded.
- 403 Forbidden — The server understood the request but refuses to authorize it.
- 404 Not Found — The requested resource could not be found.
- 405 Method Not Allowed — The request method is not supported for the resource.
- 406 Not Acceptable — The server cannot produce a response matching the list of acceptable values.
- 408 Request Timeout — The server timed out waiting for the request.
- 409 Conflict — The request conflicts with the current state of the server.
- 410 Gone — The resource is permanently gone and will not return.
- 413 Payload Too Large — The request entity is larger than the server can process.
- 414 URI Too Long — The URI provided was too long for the server to process.
- 415 Unsupported Media Type — The request body format is not supported.
- 422 Unprocessable Entity — The server understands the content type but cannot process the instructions (WebDAV).
- 429 Too Many Requests — The client has sent too many requests in a given amount of time.
400 Bad Request
400 is the generic client error code. Use it when the request syntax is malformed, required parameters are missing, or the JSON body fails schema validation. A well-designed API returns a detailed error body with 400, explaining exactly which field failed validation. Avoid using 400 for authentication failures; that is what 401 is for.
401 Unauthorized
401 means the client must authenticate to access the resource. The response must include a WWW-Authenticate header describing the authentication scheme. A common mistake is returning 401 when the client is already authenticated but lacks permission. That scenario requires 403, not 401. Remember: 401 is about identity, not authorization.
403 Forbidden
HTTP 403 Forbidden means the server understood the request and the client is authenticated, but the client does not have permission to access the resource. This is the code for insufficient privileges, IP blacklists, and geo-blocking. Unlike 401, retrying with different credentials will not help. The access is explicitly denied.
404 Not Found
What is 404? It is the most famous status code on the internet. It means the server cannot find the requested resource. This can happen because the URL was mistyped, the resource was deleted, or the routing table has no match. A good user experience replaces the default server 404 page with a helpful custom page that offers navigation options or a search box. For APIs, return a structured error body explaining that the requested entity does not exist.
429 Too Many Requests
429 indicates rate limiting. The client has exceeded the allowed number of requests in a time window. The response should include a Retry-After header telling the client when to try again. If you are building a public API, always document your rate limits and return 429 with clear messaging rather than silently dropping requests or returning 500.
5xx Server Error Responses
The 5xx class means the server failed to fulfill a valid request. These errors are the server's responsibility and should trigger alerts for the operations team. Here are the common 5xx codes:
- 500 Internal Server Error — The server encountered an unexpected condition.
- 501 Not Implemented — The server does not support the functionality required.
- 502 Bad Gateway — The server received an invalid response from an upstream server.
- 503 Service Unavailable — The server is temporarily unable to handle the request.
- 504 Gateway Timeout — The server did not receive a timely response from an upstream server.
- 505 HTTP Version Not Supported — The server does not support the HTTP protocol version used.
- 507 Insufficient Storage — The server is unable to store the representation needed (WebDAV).
- 508 Loop Detected — The server detected an infinite loop while processing the request (WebDAV).
500 Internal Server Error
HTTP 500 meaning: the server hit an unexpected condition that prevented it from fulfilling the request. This is the catch-all server error. Common causes include unhandled exceptions, database connection failures, missing environment variables, and null pointer dereferences. A 500 should never be returned intentionally. If your application can identify the specific error, return a more precise 4xx code or a specialized 5xx code like 502 or 503.
502 Bad Gateway
502 occurs when a reverse proxy or load balancer receives an invalid response from the upstream application server. This often happens when the upstream server crashes, returns malformed headers, or closes the connection prematurely. Debugging 502s usually involves checking the health of the backend services and verifying that they are not running out of memory or file descriptors.
503 Service Unavailable
HTTP 503 Service Unavailable means the server is temporarily overloaded or down for maintenance. Unlike 500, 503 is an expected and often intentional status. Use it during deployments, maintenance windows, or when auto-scaling is spinning up new instances. Always include a Retry-After header so clients and search engines know when to return. CDNs and load balancers often serve 503 when all backend pools are unhealthy.
504 Gateway Timeout
504 means the reverse proxy did not receive a response from the upstream server within the configured timeout. This is common with slow database queries, unoptimized API endpoints, or third-party integrations that hang. The fix usually involves increasing the timeout, optimizing the slow query, or adding circuit breakers to fail fast instead of waiting indefinitely.
HTTP Status Codes in REST API Design
Choosing the right status code is part of the contract between your API and its consumers. A consistent REST API status codes strategy reduces confusion and makes client error handling predictable. Here are best practices mapped to CRUD operations:
| Operation | Method | Success Code | Failure Codes |
|---|---|---|---|
| Read collection | GET /items | 200 OK | 401, 403, 429, 500 |
| Read single item | GET /items/:id | 200 OK | 400, 401, 403, 404, 429, 500 |
| Create item | POST /items | 201 Created | 400, 401, 403, 409, 422, 429, 500 |
| Full update | PUT /items/:id | 200 OK or 204 No Content | 400, 401, 403, 404, 409, 422, 429, 500 |
| Partial update | PATCH /items/:id | 200 OK or 204 No Content | 400, 401, 403, 404, 409, 422, 429, 500 |
| Delete item | DELETE /items/:id | 204 No Content | 401, 403, 404, 409, 429, 500 |
Idempotency is another consideration. GET, PUT, and DELETE should be idempotent: making the same request multiple times produces the same result. POST is not idempotent by default. If you are building an API that requires idempotent POST (for example, payment processing), implement an idempotency key pattern and return 409 Conflict if the same key is reused with different payloads.
When designing error responses, always return a consistent error object. At minimum, include the HTTP status code, a machine-readable error code, and a human-readable message. For validation errors, include a details array pointing to the specific fields that failed.
SEO Implications of HTTP Status Codes
Search engines treat HTTP status codes as signals about the quality and structure of your site. Using the wrong code can hurt rankings, waste crawl budget, and confuse indexers.
301 vs 302 for SEO: Google passes link equity (ranking signals) through 301 redirects but may not do so for 302 redirects if they remain in place long-term. If you permanently move content, always use 301 or 308. Using 302 for a permanent migration is a common SEO mistake that dilutes authority.
404 vs 410: Both tell search engines a page is gone, but 410 Gone is more explicit. Google treats 410 as a stronger signal to remove the URL from the index faster. Use 410 for pages that are permanently removed and will never return, such as expired product listings or deleted user accounts.
Soft 404s: A soft 404 occurs when a page returns 200 OK but displays a "not found" message. This confuses search engines because they see a valid page with no useful content. Google Search Console flags soft 404s, and they should be fixed by returning the proper 404 or 410 status code.
How Google handles status codes: Googlebot follows up to five consecutive redirects. After that, it aborts. It respects Retry-After on 503 and will revisit later. Prolonged 503s on important pages can eventually lead to deindexing, so use them only for short maintenance windows.
If you are migrating a large site, audit your redirects with our URL Toolkit to validate URL structures and ensure no redirect chains or loops remain.
Frequently Asked Questions
What does HTTP 404 mean?
HTTP 404 Not Found means the server cannot locate the requested resource. It is the standard response for broken links, mistyped URLs, or deleted pages. If you are a site owner, customize your 404 page to help users find what they were looking for.
What is the difference between 401 and 403?
401 Unauthorized means the client has not authenticated or the authentication failed. 403 Forbidden means the client is authenticated but does not have permission to access the resource. In short: 401 is about who you are; 403 is about what you are allowed to do.
When should I use 301 vs 302?
Use 301 for permanent URL changes, such as domain migrations or content reorganization. Use 302 (or preferably 307) for temporary changes, such as A/B tests or maintenance redirects. For SEO, 301 passes link equity while 302 generally does not.
What causes a 500 Internal Server Error?
500 errors are caused by unexpected server-side failures: unhandled exceptions, database connection drops, missing configuration, or resource exhaustion. Check your application logs immediately after a 500 to identify the stack trace and root cause.
Is 418 I'm a teapot a real status code?
Yes. 418 was defined in RFC 2324 as an April Fools' joke (Hyper Text Coffee Pot Control Protocol). It is not intended for actual use, but many developers include it as an Easter egg. Some frameworks and APIs return 418 to indicate a request that is nonsensical in context.
What is the difference between 502 and 504?
502 Bad Gateway means the upstream server returned an invalid or unexpected response. 504 Gateway Timeout means the upstream server took too long to respond. Both indicate a problem with a backend service behind a reverse proxy.
Should I return 200 or 204 for a DELETE request?
204 No Content is the preferred status for a successful DELETE because there is no resource to return. However, 200 OK with an empty body is also acceptable. Choose one convention and apply it consistently across your API.
What does HTTP 503 Service Unavailable mean?
503 means the server is temporarily unable to handle the request, usually due to maintenance or overload. It tells clients and search engines to try again later. Always include a Retry-After header when returning 503.
Can I use HTTP status codes in WebSocket communication?
WebSocket handshakes use HTTP initially, so the upgrade request can receive standard HTTP status codes like 401 or 403. Once the connection is established, WebSocket frames do not use HTTP status codes; they use WebSocket close codes instead.
Where can I look up HTTP status codes quickly?
Use our free HTTP Status Code Lookup tool for instant explanations, common causes, and fixes for any code.
Mastering http status codes makes you a more effective developer, whether you are debugging APIs, optimizing for search engines, or designing resilient systems. Bookmark this guide and our HTTP Status Code Lookup tool for quick reference. While you are here, explore our other free tools: JSON Tools, URL Toolkit, Base64 Tool, Cron Generator, and Hash Generator.