PressBuddy
Home

HTTP Status Code Checker

Reference guide and URL tester for HTTP status codes with detailed explanations

The server has received the request headers and the client should proceed to send the request body.

When to use:

Used in HTTP/1.1 when sending large request bodies to avoid sending data if the server will reject it.

Common examples:
  • POST requests with Expect: 100-continue header

The server is switching protocols as requested by the client.

When to use:

Protocol upgrade requests like WebSocket connections.

Common examples:
  • WebSocket handshake
  • HTTP to HTTPS upgrade

The server is processing the request but no response is available yet.

When to use:

Long-running operations that need to prevent client timeouts.

Common examples:
  • WebDAV requests that take time to process

The request was successful and the server returned the requested data.

When to use:

Most successful GET, POST, PUT requests where data is returned.

Common examples:
  • GET request for existing resource
  • POST request processed successfully

The request was successful and a new resource was created.

When to use:

When a new resource is successfully created via POST or PUT.

Common examples:
  • POST request that creates a new user
  • PUT request that creates a new file

The request has been accepted for processing, but processing is not complete.

When to use:

Asynchronous operations where processing happens in the background.

Common examples:
  • Async processing requests
  • Batch operations
  • Email sending

The request was successful but there is no content to return.

When to use:

Successful operations that don't need to return data to the client.

Common examples:
  • DELETE requests
  • PUT updates with no response body
  • OPTIONS requests

The server is delivering only part of the resource due to a range header.

When to use:

Range requests for partial content delivery.

Common examples:
  • Video streaming
  • File download resumption
  • Large file partial requests

The resource has been permanently moved to a new URL.

When to use:

Permanent URL changes that should update bookmarks and search engines.

Common examples:
  • Domain changes
  • URL structure changes
  • HTTPS redirects
Troubleshooting tips:
  • Check if the redirect loop exists
  • Verify the new URL is correct
  • Update internal links

The resource is temporarily available at a different URL.

When to use:

Temporary redirects where the original URL should be used in future requests.

Common examples:
  • Login redirects
  • Temporary maintenance pages
  • A/B testing
Troubleshooting tips:
  • Check if redirect is actually temporary
  • Verify redirect target
  • Look for redirect chains

The resource has not been modified since the last request.

When to use:

Conditional requests when cached content is still valid.

Common examples:
  • Cached content validation
  • Conditional GET requests with If-Modified-Since

The resource is temporarily available at a different URL, method must not change.

When to use:

Temporary redirects where the HTTP method should be preserved.

Common examples:
  • POST request temporary redirects
  • Maintenance mode redirects

The resource has been permanently moved, method must not change.

When to use:

Permanent redirects where the HTTP method should be preserved.

Common examples:
  • API endpoint changes
  • Permanent URL restructuring

The request could not be understood by the server due to malformed syntax.

When to use:

When the client sends a request that cannot be processed due to client error.

Common examples:
  • Invalid JSON in request body
  • Missing required parameters
  • Malformed URLs
Troubleshooting tips:
  • Validate request syntax
  • Check required parameters
  • Verify content-type headers
  • Review request body format

Authentication is required and has failed or has not been provided.

When to use:

When authentication is required but not provided or invalid.

Common examples:
  • Missing authentication token
  • Invalid credentials
  • Expired session
Troubleshooting tips:
  • Check authentication credentials
  • Verify token expiration
  • Ensure proper authentication headers
  • Check API key validity

The server understood the request but refuses to authorize it.

When to use:

When the user is authenticated but doesn't have permission to access the resource.

Common examples:
  • Insufficient permissions
  • IP address blocked
  • Resource access denied
Troubleshooting tips:
  • Check user permissions
  • Verify access controls
  • Review IP restrictions
  • Check resource ownership

The requested resource could not be found on the server.

When to use:

When the requested resource doesn't exist or has been removed.

Common examples:
  • Non-existent webpage
  • Deleted resource
  • Incorrect URL
Troubleshooting tips:
  • Verify URL spelling
  • Check if resource was moved
  • Review routing configuration
  • Check database records

The HTTP method used is not allowed for the requested resource.

When to use:

When the HTTP method is not supported for the specific endpoint.

Common examples:
  • POST to read-only endpoint
  • DELETE on protected resource
  • PUT without update permissions
Troubleshooting tips:
  • Check allowed HTTP methods
  • Review API documentation
  • Verify endpoint configuration
  • Use OPTIONS to check allowed methods

The request could not be completed due to a conflict with the current state.

When to use:

When the request conflicts with the current state of the resource.

Common examples:
  • Duplicate resource creation
  • Version conflicts
  • Concurrent modifications
Troubleshooting tips:
  • Check for duplicate entries
  • Review concurrent operations
  • Implement proper locking
  • Use version control

The request was well-formed but contains semantic errors.

When to use:

When the request syntax is correct but the data fails validation rules.

Common examples:
  • Validation errors
  • Business logic violations
  • Invalid data relationships
Troubleshooting tips:
  • Check validation rules
  • Review data constraints
  • Verify business logic
  • Check field formats

The client has sent too many requests in a given amount of time.

When to use:

When implementing rate limiting or when clients exceed usage limits.

Common examples:
  • API rate limiting
  • DDoS protection
  • Quota exceeded
Troubleshooting tips:
  • Check rate limit headers
  • Implement exponential backoff
  • Review usage patterns
  • Consider caching

The server encountered an unexpected condition that prevented it from fulfilling the request.

When to use:

When the server encounters an unexpected error condition.

Common examples:
  • Unhandled exceptions
  • Database connection failures
  • Configuration errors
Troubleshooting tips:
  • Check server logs
  • Review error messages
  • Verify database connectivity
  • Check configuration files
  • Monitor server resources

The server received an invalid response from an upstream server.

When to use:

When acting as a gateway or proxy and receiving invalid responses from upstream.

Common examples:
  • Proxy server errors
  • Load balancer issues
  • Upstream service failures
Troubleshooting tips:
  • Check upstream servers
  • Verify proxy configuration
  • Review load balancer health
  • Check network connectivity

The server is currently unable to handle the request due to temporary overload or maintenance.

When to use:

When the server is temporarily unable to handle requests.

Common examples:
  • Server maintenance
  • Overloaded server
  • Temporary service shutdown
Troubleshooting tips:
  • Check server capacity
  • Review maintenance schedules
  • Monitor server load
  • Implement graceful degradation

The server did not receive a timely response from an upstream server.

When to use:

When acting as a gateway and upstream servers don't respond in time.

Common examples:
  • Slow database queries
  • Upstream service timeouts
  • Network latency issues
Troubleshooting tips:
  • Check upstream response times
  • Review timeout configurations
  • Optimize slow operations
  • Check network latency
Quick Reference
Status Code Categories:
1xx - Informational
2xx - Success
3xx - Redirection
4xx - Client Error
5xx - Server Error
Most Common Status Codes:
  • 200 OK

    Request successful

  • 404 Not Found

    Resource doesn't exist

  • 500 Internal Server Error

    Server error occurred

  • 301 Moved Permanently

    Resource permanently moved

  • 401 Unauthorized

    Authentication required

  • 403 Forbidden

    Access denied

  • 502 Bad Gateway

    Invalid upstream response

Testing Tips:
  • Use developer tools

    Browser DevTools Network tab shows all HTTP responses

  • Test with curl

    Command-line tool for detailed HTTP testing

  • Check response headers

    Headers provide additional context about the response

  • Monitor response times

    Slow responses might indicate server issues

Complete HTTP Status Code Reference & Testing Tool

Our HTTP Status Code Checker provides a comprehensive reference for all HTTP response status codes along with a built-in URL tester to help developers and web administrators diagnose and understand web server responses.

Understanding HTTP Status Codes

HTTP status codes are three-digit numbers returned by web servers to indicate the result of a client's request. These codes are grouped into five categories:

1xx Informational Responses

Informational responses indicate that the request was received and understood, and processing continues:

2xx Success

Success responses indicate that the client's request was successfully received, understood, and accepted:

3xx Redirection

Redirection responses indicate that further action needs to be taken by the client to complete the request:

4xx Client Errors

Client error responses indicate that the client seems to have made an error:

5xx Server Errors

Server error responses indicate that the server failed to fulfill a valid request:

Common HTTP Status Code Scenarios

Web Development Scenarios

SEO and Website Management

Troubleshooting Common HTTP Errors

404 Not Found Errors

When encountering 404 errors, check:

500 Internal Server Errors

For 500 errors, investigate:

502 Bad Gateway Errors

Bad gateway errors often indicate:

Best Practices for HTTP Status Codes

For Web Developers

For System Administrators

Testing HTTP Status Codes

Manual Testing Methods

Automated Testing

HTTP Status Codes in Different Contexts

REST API Design

REST APIs should use HTTP status codes appropriately:

Web Applications

Content Management

Advanced HTTP Status Code Concepts

Custom Status Codes

While HTTP defines standard status codes, some applications use custom codes:

Status Code Headers

HTTP headers provide additional context for status codes:

Tools and Resources

Testing Tools

Monitoring Solutions

Our HTTP Status Code Checker tool provides an easy way to look up status codes, understand their meanings, and test URLs directly in your browser. Use it as a quick reference during development or troubleshooting to ensure your applications handle HTTP responses correctly.