HTTP Status Codes: Complete Reference Guide

HTTP Status Codes

Every HTTP response includes a status code, a three-digit number that tells the client whether the request succeeded, failed, or needs further action. Knowing what each code means makes debugging web applications significantly faster and helps you build APIs that communicate errors clearly and consistently.

How Status Codes Are Organised

HTTP status codes are grouped into five categories based on their first digit. The category tells you immediately whether the outcome was positive, negative, or something in between. The specific code within that category gives you the precise detail.

Common 2xx Success Codes

A 2xx response means the request was successful. The specific code within this range communicates exactly what kind of success occurred, which matters for clients that need to handle responses differently based on whether a resource was retrieved, created, or deleted.

Common 3xx Redirect Codes

A 3xx response tells the client that the resource it requested is available at a different URL. The new URL is provided in the Location response header. Browsers follow redirects automatically, but API clients may need to be configured to do so. The distinction between permanent and temporary redirects has significant implications for SEO and caching.

Common 4xx Client Error Codes

A 4xx response means the request itself is the source of the problem. The server understood the request but cannot or will not process it because of something the client did or did not provide. Fixing a 4xx error requires changing the request, not restarting the server.

Common 5xx Server Error Codes

A 5xx response means the server encountered a problem while processing what was otherwise a valid request. The client did nothing wrong. The fix requires action on the server side. These errors should be monitored closely in production because they represent failures in your own infrastructure.

401 vs 403 and 301 vs 302

Two pairs of status codes are frequently confused with each other because their names and descriptions sound similar. Understanding the precise difference between them prevents incorrect implementations that mislead clients.

Frequently Asked Questions

1. Why do I see 404 errors?
   A 404 means the server could not find a resource at the URL that was requested. Common causes include pages that have been deleted, URLs with typos or case mismatches, broken links pointing to content that has moved without a redirect, and API endpoints that have changed path without backwards compatibility. If you are the site owner, audit your links regularly and set up 301 redirects for any URLs that have changed permanently.
2. What causes a 500 error?
   A 500 Internal Server Error indicates an unhandled exception or unexpected condition in the server-side application code. Common causes include bugs that throw uncaught exceptions, failed database connections, missing environment variables or configuration, insufficient disk space, and memory exhaustion. Check your server logs immediately after a 500 error as they will usually contain the specific exception and stack trace needed to diagnose the problem.
3. What is the difference between 301 and 302 redirects?
   A 301 redirect tells browsers and search engines that the resource has permanently moved to a new URL. Search engines update their index to use the new URL and transfer ranking signals to it. A 302 redirect tells clients the resource is temporarily at a different URL but the original URL remains valid and should be kept in the index. Use 301 for permanent URL changes such as a domain migration or restructured paths. Use 302 for temporary situations such as maintenance redirects or A/B testing.
4. What is the difference between 400 and 422?
   Both indicate a problem with the data the client sent, but at different levels. A 400 Bad Request means the request itself is structurally invalid, such as malformed JSON that cannot be parsed, missing required headers, or a request body that cannot be read at all. A 422 Unprocessable Entity means the request was well-formed and parseable but the data failed validation rules, for example an email field that contains a string without an at sign, or an age field with a negative number. Use 422 for business logic validation failures and 400 for structural errors.
5. When should an API return 204 instead of 200?
   Return 204 No Content when a request succeeds but there is genuinely nothing meaningful to include in the response body. The most common cases are successful DELETE operations, where the deleted resource no longer exists and returning it would be redundant, and PATCH or PUT operations where the client already knows what the updated resource looks like. Return 200 OK when the response body contains useful data the client needs, such as the updated record after a PUT or a confirmation message after a POST.

Conclusion

HTTP status codes are the language servers use to communicate the outcome of every request. A 2xx response confirms success. A 3xx response directs the client elsewhere. A 4xx response points to a problem in the request. A 5xx response indicates a failure on the server. Understanding the specific meaning of each code helps you debug APIs faster, build error handling that responds appropriately to each failure type, and configure redirects correctly for both users and search engines. Continue with HTTP requests and responses, HTTP methods, and REST APIs for a complete understanding of how HTTP communication works.