HTTP Status Code Lookup

Quick-reference guide to every HTTP status code: 1xx informational, 2xx success, 3xx redirects, 4xx client errors, 5xx server errors. Search, filter, and copy.

Understanding HTTP Status Code Categories

1xx Informational

The request was received and is being processed. These are interim responses. Examples: 100 Continue, 101 Switching Protocols, 103 Early Hints.

2xx Success

The request was successfully received, understood, and accepted. Examples: 200 OK, 201 Created, 204 No Content, 206 Partial Content.

3xx Redirection

Further action is needed to complete the request. Examples: 301 Moved Permanently, 302 Found, 304 Not Modified, 307 Temporary Redirect.

4xx Client Error

The request contains bad syntax or cannot be fulfilled. Examples: 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests.

5xx Server Error

The server failed to fulfill a valid request. Examples: 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout.

Custom Codes

Some platforms use non-standard codes (e.g., Cloudflare 52x errors, IIS 440 Login Timeout). Use standard codes when possible for better compatibility.

Common Status Codes Explained

OK

Standard success response. The request was successful and the server returned the requested data.

Created

A new resource was successfully created (typically in response to POST or PUT requests).

Bad Request

The server cannot process the request due to client error (malformed syntax, invalid parameters, etc.).

Not Found

The requested resource could not be found on the server. This is the most common error status code.

Internal Server Error

A generic server error occurred. The server encountered an unexpected condition that prevented it from fulfilling the request.

Best Practices for API Design

  • Use semantic codes: Choose status codes that accurately describe the result (200 for success, 404 for not found, 500 for server errors)

  • Be consistent: Use the same status codes for similar situations across your API

  • Provide error details: Include helpful error messages in the response body along with appropriate status codes

  • Use 201 for resource creation: Return 201 Created with a Location header pointing to the new resource

  • Distinguish authentication vs authorization: Use 401 for missing/invalid auth, 403 for insufficient permissions

  • Implement rate limiting: Return 429 Too Many Requests with Retry-After header when rate limits are exceeded

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

ClassRangeMeaningExamples
1xx100-199Informational — request received, processing continues100 Continue, 101 Switching Protocols
2xx200-299Success — request received, understood, and accepted200 OK, 201 Created, 204 No Content
3xx300-399Redirection — further action needed to complete request301 Moved Permanently, 302 Found, 304 Not Modified
4xx400-499Client Error — request contains errors or cannot be fulfilled400 Bad Request, 401 Unauthorized, 404 Not Found
5xx500-599Server Error — server failed to fulfill a valid request500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable

Most Common Status Codes

CodeNameWhen Returned
200OKRequest succeeded — response contains the requested resource
201CreatedResource was successfully created (POST/PUT)
204No ContentSuccess, but no response body (DELETE, updates)
301Moved PermanentlyResource has a new permanent URL — update bookmarks
304Not ModifiedCached version is still valid — no data transfer needed
400Bad RequestRequest syntax or parameters are invalid
401UnauthorizedAuthentication required or failed
403ForbiddenAuthenticated but not authorized for this resource
404Not FoundResource does not exist at this URL
429Too Many RequestsRate limit exceeded — slow down
500Internal Server ErrorGeneric server failure — check server logs
502Bad GatewayUpstream server returned an invalid response
503Service UnavailableServer 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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. Log all 5xx errors — Every 500-level response represents a server failure that needs investigation. Ensure comprehensive logging for all 5xx responses.
Advertisement

Frequently Asked Questions

What are HTTP status codes and why are they important?+

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.

What is the difference between 301, 302, 307, and 308 redirects?+

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.

What do 4xx client error codes mean and how do I fix them?+

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.

What do 5xx server error codes mean and how do I troubleshoot them?+

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.

How do status codes affect SEO and search engine rankings?+

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.

What are some lesser-known but useful HTTP status codes?+

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.

How should APIs use status codes for RESTful responses?+

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.

What HTTP status codes should I use for API rate limiting and throttling?+

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.

This tool is provided for informational and educational purposes only. All processing happens in your browser — no data is sent to or stored on our servers. While we strive for accuracy, we make no warranties about the completeness or reliability of results.