What Are HTTP Status Codes?
HTTP status codes are three-digit numbers returned by a server in response to a client's request. They are a fundamental part of the HTTP protocol and communicate the outcome of every request made to a web server. Whether you are browsing a website, consuming a REST API, or debugging a web application, status codes tell you whether the request succeeded, failed, was redirected, or encountered an error on the server side.
The first digit of a status code defines its class. Codes starting with 1 are informational, 2 indicates success, 3 represents redirection, 4 signals a client error, and 5 denotes a server error. Understanding these classes and their most common codes is essential for anyone working with web technologies, from frontend developers and backend engineers to DevOps specialists and QA testers. You can use our HTTP Status Code Checker to quickly look up any code and understand its meaning.
1xx — Informational Responses
Informational responses are rare in everyday web browsing but play important roles in specific protocols and persistent connections. They indicate that the server has received the request and is continuing the process. Most developers encounter these codes infrequently, but understanding them helps when debugging complex networking issues or working with WebSockets, HTTP/2, and long-lived connections.
100 Continue
The 100 Continue status code tells the client that the server has received the request headers and that the client should proceed to send the request body. This is used when a client sends a request with an Expect: 100-continue header, typically for large file uploads. The server can either respond with 100 Continue to accept the body or with an error code like 417 Expectation Failed to reject it, saving bandwidth by preventing the client from transmitting a large payload that the server would reject.
101 Switching Protocols
The 101 Switching Protocols code is sent in response to an Upgrade header, indicating that the server agrees to change the application protocol being used on the connection. This is most commonly used when establishing WebSocket connections, where the initial HTTP handshake is upgraded to a persistent, bidirectional communication channel. Without this code, real-time features like chat applications, live notifications, and collaborative editing would not be possible over standard HTTP.
2xx — Success Responses
Success responses indicate that the server received, understood, and successfully processed the client's request. These are the codes every developer wants to see when testing their applications. However, not all success codes mean the same thing, and understanding the nuances between them helps you write more precise APIs and handle responses more gracefully on the frontend.
200 OK
The 200 OK status code is the most common success response. It indicates that the request was successful and the response body contains the requested data. When you load a webpage, a 200 response delivers the HTML content. When you call a REST API endpoint with a GET request, a 200 response returns the data you asked for. It is the default success response for most well-formed requests and represents normal operation.
201 Created
The 201 Created code indicates that the request was successful and a new resource was created as a result. This is typically returned in response to POST requests, such as when you create a new user account, submit a form, or add a new record to a database. A 201 response should include a Location header pointing to the URI of the newly created resource, allowing the client to retrieve or reference it immediately after creation.
204 No Content
The 204 No Content code indicates that the request was successful but there is no data to return in the response body. This is commonly used with PUT, PATCH, or DELETE requests where the action succeeded but there is nothing meaningful to send back. Using 204 instead of 200 with an empty body is semantically more accurate and can improve network performance by eliminating unnecessary data transfer and body parsing overhead.
3xx — Redirection Responses
Redirection responses tell the client that the requested resource is available at a different URL. The client must take additional action to complete the request, usually by following the new URL provided in the Location header. Redirects are fundamental to how the web works, enabling URL changes, SEO canonicalization, load balancing, and SSL enforcement. Understanding the difference between temporary and permanent redirects is critical for web developers and SEO specialists.
301 Moved Permanently
The 301 status code indicates that the resource has been permanently moved to a new URL. Search engines update their indexes to point to the new URL, and browsers cache this redirect so future requests go directly to the new location. You should use a 301 redirect when changing your domain, restructuring URLs, or migrating from HTTP to HTTPS. This preserves search engine rankings and link equity, ensuring users and crawlers always reach the correct page.
302 Found
The 302 status code indicates a temporary redirect. Unlike 301, this tells search engines to keep the original URL in their indexes because the change is not permanent. Browsers may or may not cache a 302 redirect, and the original URL should still be used for future requests. Use 302 when a page is temporarily unavailable at its usual URL and you want to send users to an alternative location without affecting SEO rankings or link equity.
304 Not Modified
The 304 Not Modified code is a special redirect that tells the client the resource has not changed since the last request. When a browser sends conditional headers like If-None-Match (with an ETag) or If-Modified-Since (with a date), the server checks whether the resource has changed. If it has not, the server responds with 304 and no body, saving significant bandwidth. This mechanism powers browser caching and dramatically improves page load performance for returning visitors.
307 Temporary Redirect
The 307 Temporary Redirect is similar to 302 but with an important distinction: it ensures the HTTP method and body are preserved when the client follows the redirect. With 302, some clients may change a POST request to a GET request when following the redirect, which can cause unexpected behavior. Use 307 when you need to temporarily redirect POST, PUT, or PATCH requests and want to guarantee that the original method is maintained.
4xx — Client Error Responses
Client error responses indicate that the request contains bad syntax or cannot be fulfilled due to a problem on the client side. These are the errors users encounter most frequently, and they are almost always caused by issues with the request itself rather than the server. Understanding these codes helps developers build better error handling, improve user experience, and debug API integration problems efficiently.
400 Bad Request
The 400 Bad Request code means the server could not understand the request due to malformed syntax, invalid parameters, or missing required fields. This often happens when submitting forms with invalid data, sending malformed JSON in an API request, or including characters the server cannot parse. The response body usually includes details about what was wrong, helping developers identify and fix the issue quickly.
401 Unauthorized
The 401 Unauthorized code indicates that the request requires authentication and the client has not provided valid credentials. Despite the misleading name, this code means "unauthenticated" rather than "unauthorized." It is returned when a user tries to access a protected resource without being logged in or when an authentication token has expired. The response typically includes a WWW-Authenticate header describing the authentication scheme required.
403 Forbidden
The 403 Forbidden code means the server understood the request and the client is authenticated, but the client does not have permission to access the requested resource. This happens when a user tries to access an admin page without admin privileges, when an IP address is blocked, or when directory listing is disabled. Unlike 401, re-authenticating will not help because the server has already identified the client and determined they lack the necessary permissions.
404 Not Found
The 404 Not Found code is perhaps the most well-known HTTP status code. It indicates that the server cannot find the requested resource at the given URL. This can happen because the URL is misspelled, the page has been deleted, or the resource was never created. A well-designed 404 page improves user experience by helping visitors navigate back to useful content instead of staring at a dead-end error message.
405 Method Not Allowed
The 405 Method Not Allowed code indicates that the HTTP method used (GET, POST, PUT, DELETE, etc.) is not supported for the requested resource. For example, if a REST API endpoint only accepts POST requests but the client sends a GET request, the server responds with 405. The response should include an Allow header listing the methods that are valid for the resource, helping developers correct their requests.
408 Request Timeout
The 408 Request Timeout code indicates that the server did not receive a complete request from the client within the time the server was prepared to wait. This can happen on slow network connections, when a client stalls during a large upload, or when a reverse proxy times out waiting for the client to finish sending data. Retrying the request is often sufficient to resolve this error.
429 Too Many Requests
The 429 Too Many Requests code indicates that the client has sent too many requests in a given amount of time. This is the server's way of rate limiting to prevent abuse, DDoS attacks, and resource exhaustion. The response typically includes a Retry-After header telling the client how long to wait before making another request. Rate limiting is essential for protecting public APIs and preventing brute-force attacks on authentication endpoints.
5xx — Server Error Responses
Server error responses indicate that something went wrong on the server side and the server could not fulfill a valid request. These errors are not the client's fault and usually require intervention from the server or application development team. They can be caused by software bugs, server misconfigurations, database failures, or infrastructure issues. Monitoring and alerting on 5xx errors is critical for maintaining service reliability and minimizing downtime.
500 Internal Server Error
The 500 Internal Server Error is a catch-all response for unexpected server-side failures. It means something went wrong that the server does not know how to handle or does not want to disclose, such as an unhandled exception in application code, a failed database connection, or a configuration error. This is the most common 5xx code and often requires checking server logs to identify the root cause. Well-architected applications should catch exceptions and return more specific error codes when possible.
502 Bad Gateway
The 502 Bad Gateway code indicates that the server, acting as a gateway or proxy, received an invalid response from an upstream server. This typically happens in microservices architectures, reverse proxy setups with Nginx or HAProxy, or when using content delivery networks. The gateway server is working correctly, but the backend service it is trying to reach is returning malformed responses or is completely unreachable. Common causes include crashed backend processes, network partitions, and incorrect proxy configurations.
503 Service Unavailable
The 503 Service Unavailable code means the server is temporarily unable to handle the request, usually due to maintenance or overload. Unlike 500, this is often a deliberate response indicating the server is aware of the problem. The response typically includes a Retry-After header to tell clients when they should try again. This code is commonly returned during deployments, when the server is running at capacity, or when a required dependency like a database is down.
504 Gateway Timeout
The 504 Gateway Timeout code indicates that the server, acting as a gateway or proxy, did not receive a timely response from an upstream server. Unlike 502, where the upstream server sends an invalid response, in a 504 scenario the upstream server simply does not respond within the timeout period. This commonly happens when a backend service is processing a slow query, when there is heavy traffic causing request queuing, or when network latency between gateway and backend exceeds configured timeout thresholds.
Common Debugging Scenarios
Debugging HTTP status codes effectively requires a systematic approach. Start by identifying the code class — if it is a 4xx error, the problem is likely with the client request. Check the request URL, headers, parameters, and authentication credentials. If it is a 5xx error, the problem is on the server side, and you should check server logs, database connectivity, and configuration files. Browser developer tools and API testing tools like Postman, Insomnia, or curl are invaluable for inspecting request and response details.
When building APIs, return meaningful error messages alongside status codes to help consumers debug issues quickly. Include details about which fields failed validation, what authentication scheme is required, or why a resource was not found. For web applications, implement user-friendly error pages that explain what went wrong and provide navigation options. Monitoring tools like Datadog, New Relic, or Sentry can alert you to spikes in error rates before they impact a significant number of users, allowing you to respond proactively.
Key Takeaways
- HTTP status codes are three-digit numbers grouped into five classes: informational (1xx), success (2xx), redirection (3xx), client errors (4xx), and server errors (5xx).
- 200 OK is the standard success response, while 201 Created indicates resource creation and 204 No Content confirms an action with no data to return.
- Use 301 for permanent redirects, 302 for temporary ones, 304 for cache validation, and 307 when the HTTP method must be preserved during a redirect.
- 400 indicates a malformed request, 401 means missing authentication, 403 means insufficient permissions, 404 means the resource does not exist, and 429 signals rate limiting.
- 500 is a catch-all server error, 502 means a gateway received an invalid upstream response, 503 indicates temporary unavailability, and 504 means an upstream timeout.
- Effective debugging requires identifying the error class, inspecting request and response details with developer tools, and setting up monitoring for error rate spikes.
Frequently Asked Questions
What is the difference between 401 and 403?
A 401 Unauthorized response means the client has not provided valid authentication credentials — the server does not know who is making the request. A 403 Forbidden response means the client is authenticated but does not have permission to access the requested resource — the server knows who you are but has determined you are not allowed. Re-authenticating may resolve a 401, but it will not resolve a 403 because the server has already verified your identity and denied access.
Should I use 301 or 302 for my redirects?
Use a 301 redirect when the URL change is permanent, such as when changing your domain name, restructuring URLs, or migrating from HTTP to HTTPS. Use a 302 redirect when the change is temporary, such as during maintenance or A/B testing. Using the wrong redirect type can negatively impact SEO — a 301 passes link equity to the new URL, while a 302 keeps the original URL indexed in search engines.
How do I handle 429 Too Many Requests in my application?
When you receive a 429 response, check the Retry-After header to determine how long to wait before making another request. In your own APIs, implement rate limiting with clear error messages and Retry-After headers to guide clients. For client applications, implement exponential backoff with jitter to avoid thundering-herd problems. If you consistently hit rate limits, consider requesting a higher quota from the API provider or optimizing your request patterns to batch operations and reduce unnecessary calls.