HTTP Status Codes: Complete Reference Guide for Developers
A complete reference for all HTTP status codes from 1xx to 5xx — what they mean, when they occur, and how to handle them in your applications.
Try the free online tool
Runs entirely in your browser — no signup, no uploads.
HTTP status codes are three-digit numbers returned by a server in response to a client's request. They tell the client whether the request was successful, redirected, or encountered an error. Every developer working with web applications or APIs encounters these codes daily, yet many only know the most common ones like 200 OK or 404 Not Found.
Understanding the full range of HTTP status codes — from the informational 1xx series all the way to server-error 5xx codes — helps you build more robust applications, write better error-handling logic, and debug issues faster. Whether you're building a REST API, troubleshooting a production incident, or reviewing server logs, fluency with status codes is an essential skill.
This reference tool lets you quickly search and look up any status code, understand its meaning, and see real-world examples of when you'd encounter it. Use it as a companion while developing APIs, configuring web servers, or handling HTTP responses in your client-side code.
What Are HTTP Status Codes?
HTTP status codes are standardized numeric codes defined in RFC 7231 (and updated in later RFCs) that servers return to indicate the result of a client's HTTP request. They are grouped into five classes based on the first digit.
The 1xx informational codes indicate that a request was received and processing is continuing. The 2xx success codes confirm that a request was received, understood, and accepted. The 3xx redirection codes mean further action is needed to complete the request. The 4xx client error codes indicate that the request contains an error or cannot be fulfilled due to the client's input. The 5xx server error codes indicate that the server failed to fulfill a valid request.
Each class signals a fundamentally different outcome and requires a different response from the client application. Proper use of status codes is a hallmark of well-designed HTTP APIs.
How to Use This Tool
Look up any HTTP status code instantly using the search or browse interface below.
- 1
Enter a code or keyword
Type a three-digit status code (e.g., 429) or a keyword like 'redirect' into the search box to filter results.
- 2
Browse by category
Use the 1xx–5xx category tabs to browse all codes within a particular class at a glance.
- 3
Read the description
Each result shows the official code name, a plain-English description, and the RFC reference where it is defined.
- 4
Review common causes
Expand a code to see common scenarios in which it is returned and typical client or server actions to take.
- 5
Copy for documentation
Use the copy button to grab the code, name, and description for inclusion in API docs or error-handling comments.
Common Use Cases
HTTP status codes come up in many everyday development scenarios.
- Designing REST API responses — choosing the right code (201 Created vs. 200 OK) for each endpoint action.
- Debugging failed API calls — reading the status code returned by a third-party API to understand why a request failed.
- Configuring web server redirects — setting up 301 Permanent vs. 302 Temporary redirects correctly.
- Writing client-side error handling — branching on 4xx vs. 5xx to show appropriate user messages or retry logic.
- Reviewing access logs and monitoring dashboards — interpreting spikes in 4xx or 5xx error rates as early warning signals.
Tips and Best Practices
Use these guidelines to work with HTTP status codes effectively.
- Always return the most semantically correct code — returning 200 for an error confuses clients and monitoring tools.
- Pair status codes with a descriptive response body — include an error message or error code so clients can act on failures.
- Use 422 Unprocessable Entity for validation errors, not 400 Bad Request, when the syntax is correct but the data is invalid.
- Avoid using 200 OK for empty results — 204 No Content is more accurate when there is nothing to return.
- Document every non-200 status code your API can return so API consumers know what to expect and handle.
Frequently Asked Questions
What is the difference between 401 and 403?
401 Unauthorized means the request lacks valid authentication credentials — the client should authenticate and try again. 403 Forbidden means the server understood the request and the client is authenticated, but does not have permission to access the resource.
When should I use 301 vs. 302 redirects?
Use 301 Moved Permanently when a resource has been permanently relocated and search engines should update their index. Use 302 Found (or 307 Temporary Redirect) when the move is temporary and the original URL will be used again.
What does a 429 Too Many Requests status mean?
429 means the client has sent too many requests in a given period and has been rate-limited by the server. The response may include a Retry-After header indicating how long to wait before trying again.
Is 404 returned only when a page does not exist?
404 Not Found is returned whenever the server cannot locate the requested resource — this includes pages, API endpoints, files, or any other resource. It does not necessarily mean the resource never existed; it may have been deleted or the URL may be wrong.
What is the difference between 500 and 503?
500 Internal Server Error is a generic error indicating something went wrong on the server. 503 Service Unavailable means the server is temporarily unable to handle the request, often due to maintenance or being overloaded, and is expected to recover.
Should I return 200 or 204 when deleting a resource?
204 No Content is the preferred status for a successful DELETE request where there is no response body. 200 OK is acceptable if you return a confirmation body, though 204 is more semantically precise.
What does the 418 I'm a Teapot status code mean?
418 is an April Fools' joke defined in RFC 2324 for the Hyper Text Coffee Pot Control Protocol. It means the server refuses to brew coffee because it is a teapot. It is not used in production but appears in developer easter eggs.
Ready to use this tool?
Free, instant, no account required. Runs entirely in your browser.