HTTP status codes are three-digit numbers that tell you whether a web request succeeded, failed, or needs further action. Understanding these codes is essential for debugging websites, building APIs, and troubleshooting server issues. This guide covers every status code category you need to know as a developer.
1xx Informational Status Codes Explained
Informational status codes (100-199) indicate that a request was received and the server is processing it. These codes rarely appear in typical web development but are important for understanding HTTP communication flow.
100 Continue: The server has received the request headers and the client should proceed to send the request body. This is commonly used when clients upload large files.
101 Switching Protocols: The server is switching to a different protocol as requested by the client, typically from HTTP to WebSocket. You’ll see this when establishing real-time connections.
102 Processing (WebDAV): The server is processing the request but hasn’t completed it yet. This prevents the client from timing out during long operations.
Most developers won’t need to handle these codes directly, but understanding them helps when working with advanced protocols like WebSockets or file uploads.
2xx Success Status Codes: What They Mean
Success codes (200-299) indicate that the request succeeded. These are the responses you want to see in your logs.
200 OK: The most common success code. The request succeeded and the server returned the requested data. This is your baseline for successful HTTP requests.
201 Created: The request succeeded and the server created a new resource. Use this when your API endpoint creates something new, like a new user account or blog post.
202 Accepted: The request was accepted but hasn’t been fully processed yet. Perfect for asynchronous operations where processing happens in the background.
204 No Content: The request succeeded but there’s no content to return. Common for DELETE operations or when a POST doesn’t need to return data.
206 Partial Content: The server is returning only part of the resource. Used for resume downloads or streaming video where you request specific byte ranges.
When building APIs or websites, returning the correct 2xx code helps clients understand what happened. A 201 for creation is much clearer than a generic 200.
3xx Redirection: Navigation and Caching
Redirection codes (300-399) tell the client that additional action is needed, usually following a different URL.
301 Moved Permanently: The resource moved to a new URL permanently. Search engines will update their index to the new URL. Use this when you permanently restructure your site.
302 Found (Temporary Redirect): The resource temporarily moved to a different URL. The client should keep using the original URL in future requests.
304 Not Modified: The resource hasn’t changed since the client last requested it. The client can use its cached version. This is crucial for performance optimization.
307 Temporary Redirect: Similar to 302, but guarantees the HTTP method won’t change (POST stays POST, not converted to GET).
308 Permanent Redirect: Similar to 301, but the HTTP method is preserved.
Proper use of redirect codes improves SEO and user experience. A 301 tells search engines to follow the redirect, while 302 tells them to keep checking the original URL.
4xx Client Error Codes: Request Problems
Client errors (400-499) mean the request itself had a problem. These are issues the client needs to fix.
400 Bad Request: The server can’t process the request due to malformed syntax. Check your JSON formatting, required parameters, or request headers.
401 Unauthorized: Authentication is required but missing or invalid. The client needs to provide valid credentials (API key, JWT token, etc.).
403 Forbidden: The client is authenticated but doesn’t have permission for this resource. Different from 401—the user is logged in but restricted.
404 Not Found: The requested resource doesn’t exist. The URL is wrong or the resource was deleted.
429 Too Many Requests: The client is sending too many requests too quickly. Implement rate limiting and respect this code to avoid temporary blocks.
422 Unprocessable Entity: The request is well-formed but contains semantic errors. Use this when validation fails (invalid email format, weak password, etc.).
When your API returns 4xx codes, include helpful error messages so clients understand what went wrong.
5xx Server Error Codes: Your Problem
Server errors (500-599) mean something went wrong on the server side. These require your attention.
500 Internal Server Error: Something unexpected happened on the server. A generic catch-all for unhandled exceptions. Check your server logs immediately.
502 Bad Gateway: The server received an invalid response from an upstream server. Common in load-balanced setups where one server is down.
503 Service Unavailable: The server is temporarily unavailable, usually for maintenance. Good to return this during planned downtime.
504 Gateway Timeout: The upstream server didn’t respond in time. Check if your backend services are running or if there’s a network issue.
Seeing 5xx errors means your application has a bug or infrastructure issue. Monitor these codes closely and set up alerts.
How to Use Our HTTP Status Code Calculator
Want to quickly reference status codes during development? Our HTTP calculator tools help you understand what each code means in context. Simply input the status code you’re troubleshooting, and get instant explanations, common causes, and recommended fixes. This saves time when debugging API responses or server issues.
Frequently Asked Questions
What’s the difference between 401 and 403?
401 Unauthorized means the client hasn’t authenticated. They need to log in or provide credentials. 403 Forbidden means they’re already authenticated but don’t have permission for that resource. Think of it this way: 401 is “Who are you?” while 403 is “I know who you are, but you can’t go there.”
Should I use 200 or 204 for successful API responses?
Use 200 when returning data to the client. Use 204 when the action succeeded but there’s no data to send back (like a successful DELETE operation). Both are correct—it depends on whether you have a response body.
How should I handle 5xx errors in production?
Always log 5xx errors with full context (request parameters, stack trace, timestamp). Set up monitoring and alerts to notify your team immediately. Return generic error messages to clients without exposing sensitive details. Implement automatic error recovery where possible, and provide a maintenance page if the outage is widespread.