Want to learn more?
Learn about HTTP response codes from 1xx informational to 5xx server errors and how to handle them.
Read the guideAPI Error Handling Questions?
Our developers build robust APIs with proper status codes, error messages, and documentation.
What Are HTTP Status Codes
HTTP status codes are three-digit numbers returned by web servers in response to client requests. They indicate whether a request was successful, redirected, resulted in a client error, or caused a server error. Understanding status codes is essential for web development, API design, debugging, and monitoring.
Status codes are defined by RFC 9110 (HTTP Semantics) and organized into five classes based on their first digit. This tool provides a comprehensive reference for all standard and common non-standard status codes with explanations, use cases, and debugging guidance.
Status Code Classes
| Class | Range | Meaning | Examples |
|---|---|---|---|
| 1xx | 100-199 | Informational — request received, processing continues | 100 Continue, 101 Switching Protocols |
| 2xx | 200-299 | Success — request received, understood, and accepted | 200 OK, 201 Created, 204 No Content |
| 3xx | 300-399 | Redirection — further action needed to complete request | 301 Moved Permanently, 302 Found, 304 Not Modified |
| 4xx | 400-499 | Client Error — request contains errors or cannot be fulfilled | 400 Bad Request, 401 Unauthorized, 404 Not Found |
| 5xx | 500-599 | Server Error — server failed to fulfill a valid request | 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable |
Most Common Status Codes
| Code | Name | When Returned |
|---|---|---|
| 200 | OK | Request succeeded — response contains the requested resource |
| 201 | Created | Resource was successfully created (POST/PUT) |
| 204 | No Content | Success, but no response body (DELETE, updates) |
| 301 | Moved Permanently | Resource has a new permanent URL — update bookmarks |
| 304 | Not Modified | Cached version is still valid — no data transfer needed |
| 400 | Bad Request | Request syntax or parameters are invalid |
| 401 | Unauthorized | Authentication required or failed |
| 403 | Forbidden | Authenticated but not authorized for this resource |
| 404 | Not Found | Resource does not exist at this URL |
| 429 | Too Many Requests | Rate limit exceeded — slow down |
| 500 | Internal Server Error | Generic server failure — check server logs |
| 502 | Bad Gateway | Upstream server returned an invalid response |
| 503 | Service Unavailable | Server is overloaded or in maintenance |
Common Use Cases
- API development: Choose the correct status code for each API response to follow HTTP semantics and help clients handle responses appropriately
- Debugging: Quickly look up unfamiliar status codes encountered during development and troubleshooting
- Monitoring and alerting: Configure monitoring to alert on specific status codes (spike in 5xx errors, unexpected 401s, 429 rate limiting)
- SEO optimization: Ensure redirects use correct codes (301 for permanent, 302 for temporary) to preserve search engine rankings
- Load balancer configuration: Configure health checks and error handling based on backend status codes
Best Practices
- Use specific codes, not just 200 and 500 — Return 201 for created resources, 204 for successful deletions, 404 for missing resources, and 409 for conflicts. Specific codes help clients handle responses correctly.
- Return 401 vs 403 correctly — 401 means "you need to authenticate." 403 means "you authenticated but lack permission." Conflating them leaks information about resource existence.
- Use 429 with Retry-After — When rate limiting, return 429 Too Many Requests with a Retry-After header telling the client when to try again.
- Never return 200 with an error body — Some APIs return 200 OK with {"error": "not found"} in the body. This breaks HTTP semantics and confuses monitoring, caching, and client error handling.
- Log all 5xx errors — Every 500-level response represents a server failure that needs investigation. Ensure comprehensive logging for all 5xx responses.
References & Citations
- IETF. (2022). RFC 9110: HTTP Semantics (Status Codes). Retrieved from https://www.rfc-editor.org/rfc/rfc9110.html#name-status-codes (accessed January 2025)
- MDN Web Docs. (2024). HTTP Status Code Definitions. Retrieved from https://developer.mozilla.org/en-US/docs/Web/HTTP/Status (accessed January 2025)
Note: These citations are provided for informational and educational purposes. Always verify information with the original sources and consult with qualified professionals for specific advice related to your situation.
Key Security Terms
Understand the essential concepts behind this tool
Frequently Asked Questions
Common questions about the HTTP Status Code Lookup
HTTP status codes are 3-digit responses from servers indicating request results. Categories: 1xx (informational), 2xx (success), 3xx (redirection), 4xx (client error), 5xx (server error). Purpose: communicate success/failure, enable proper error handling, assist debugging, affect SEO rankings. Common codes: 200 OK (success), 404 Not Found (missing resource), 500 Internal Server Error (server problem). Clients use codes to: retry on 503, cache 200 responses, follow 301 redirects, display error messages. Essential for web APIs, browser behavior, and application logic.
Redirect codes indicate resource moved: 301 Moved Permanently: permanent redirect, search engines transfer SEO value, browsers cache it. 302 Found (temporary): temporary redirect, search engines keep original URL, may not cache. 307 Temporary Redirect: like 302 but preserves request method (POST stays POST), more explicit about temporary nature. 308 Permanent Redirect: like 301 but preserves request method, newer standard (RFC 7538). Use 301 for: domain changes, HTTPS migration, permanent URL changes. Use 302/307 for: A/B testing, maintenance mode, temporary moves. Modern practice: prefer 307/308 over 302/301 when method preservation matters.
4xx errors indicate client-side problems: 400 Bad Request: malformed syntax, invalid data. Fix: validate request format. 401 Unauthorized: missing/invalid authentication. Fix: provide credentials. 403 Forbidden: authenticated but not authorized. Fix: check permissions. 404 Not Found: resource doesn't exist. Fix: verify URL, check routes. 405 Method Not Allowed: wrong HTTP method (GET vs POST). Fix: use correct method. 408 Request Timeout: client took too long. Fix: optimize request speed. 429 Too Many Requests: rate limit exceeded. Fix: implement backoff, reduce frequency. Client fixes: validate input, provide auth, check URLs, respect rate limits.
5xx errors indicate server-side failures: 500 Internal Server Error: generic error, something broke. Check: server logs, exceptions, database connections. 502 Bad Gateway: upstream server returned invalid response. Check: proxy configuration, upstream server health. 503 Service Unavailable: temporary overload or maintenance. Check: server capacity, recent deploys. 504 Gateway Timeout: upstream server didn't respond in time. Check: upstream performance, timeout settings, database queries. Troubleshooting: check error logs, monitor server resources (CPU, memory), verify dependencies (database, APIs), review recent code changes, check network connectivity. Users should: retry request, wait during maintenance, contact support if persists.
Search engines use status codes for crawling decisions: 200 OK: page indexed normally, good. 301 Permanent Redirect: link equity transfers to new URL, search engines update index. 302/307 Temporary: link equity stays with original, doesn't update index. 404 Not Found: page removed from index, some 404s are normal (old content). 410 Gone: stronger signal than 404, permanent removal. 503 Service Unavailable: temporary, search engines retry later, prolonged 503 can cause deindexing. Best practices: use 301 for permanent changes, fix 404s on important pages or redirect them, serve 410 for intentionally removed content, avoid soft 404s (200 status but "not found" content). Monitor crawl errors in Google Search Console.
Useful specialized codes: 206 Partial Content: for range requests, video streaming, resumable downloads. 304 Not Modified: cached version still valid, saves bandwidth. 409 Conflict: request conflicts with resource state, duplicate entry, versioning conflict. 410 Gone: resource permanently deleted (stronger than 404). 418 I'm a teapot: April Fools joke (RFC 2324), actually implemented by some servers. 422 Unprocessable Entity: syntactically correct but semantically invalid data. 451 Unavailable For Legal Reasons: censorship, DMCA takedowns. 429 Too Many Requests: rate limiting, include Retry-After header. Use when: 206 for large files, 409 for optimistic locking, 422 for validation errors, 451 for compliance.
RESTful API status code conventions: GET success: 200 OK with body, 404 if not found. POST create: 201 Created with Location header, 400 for invalid data, 409 for duplicate. PUT update: 200 OK with body, 204 No Content without body, 404 if doesn't exist. PATCH partial update: 200 OK, 204 No Content. DELETE: 204 No Content, 200 if returning deleted resource, 404 if already gone. Errors: 400 for validation errors, 401 for missing auth, 403 for insufficient permissions, 422 for semantic errors, 500 for server errors. Include error details in response body. Consistent patterns improve API usability.
Rate limiting status codes: 429 Too Many Requests: standard for rate limit exceeded. Include headers: Retry-After: 60 (seconds to wait), X-RateLimit-Limit: 1000 (total allowed), X-RateLimit-Remaining: 0 (requests left), X-RateLimit-Reset: 1234567890 (Unix timestamp). Alternative: 503 Service Unavailable with Retry-After (for overload, not just rate limit). Client behavior: respect Retry-After header, implement exponential backoff, reduce request rate. Best practices: return 429 before processing request (fail fast), provide clear error messages, document rate limits, offer different tiers if applicable. Modern APIs use 429 exclusively for rate limiting, making it distinct from server errors.