Advertisement

HTTP Status Codes Reference

Browse all HTTP status codes with descriptions, use cases, and quick search filtering.

Showing 60 of 60 status codes

100

Continue

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

Used with large POST/PUT requests to check if the server will accept the request before sending the body.
101

Switching Protocols

The server is switching protocols as requested by the client via the Upgrade header.

WebSocket connections upgrade from HTTP to the WebSocket protocol using this status.
102

Processing

The server has received and is processing the request, but no response is available yet.

Used for long-running WebDAV operations to prevent client timeouts.
103

Early Hints

Used to return some response headers before the final HTTP message.

Allows preloading resources like CSS and fonts while the server prepares the full response.
200

OK

The request has succeeded. The meaning depends on the HTTP method used.

Standard response for successful GET, POST, PUT, PATCH requests that return data.
201

Created

The request has been fulfilled and a new resource has been created.

Returned after a successful POST request that creates a new database record or resource.
202

Accepted

The request has been accepted for processing, but the processing has not been completed.

Used for asynchronous operations like batch jobs, email sending, or queued tasks.
203

Non-Authoritative Information

The returned metadata is from a local or third-party copy, not the origin server.

Used by proxies that transform the origin response, such as adding metadata.
204

No Content

The server successfully processed the request but is not returning any content.

Common response for DELETE requests or form submissions where no response body is needed.
205

Reset Content

The server successfully processed the request and asks the client to reset the document view.

Used to tell the browser to clear the form that caused the request to be sent.
206

Partial Content

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

Used for video/audio streaming and resumable file downloads with Range headers.
207

Multi-Status

The response body contains multiple status codes for multiple independent operations.

Used in WebDAV when multiple operations on multiple resources return different results.
208

Already Reported

Members of a DAV binding have already been enumerated in a previous reply.

Avoids enumerating the same collection members repeatedly in WebDAV.
226

IM Used

The server has fulfilled a GET request for the resource with instance-manipulations applied.

Used with delta encoding to send only changes to a resource rather than the full representation.
300

Multiple Choices

The request has more than one possible response. The user or user agent should choose one.

Used when a resource is available in multiple formats, like different video resolutions.
301

Moved Permanently

The resource has been permanently moved to a new URL. All future requests should use the new URL.

SEO-friendly permanent redirect when a page URL changes. Passes link equity to the new URL.
302

Found

The resource is temporarily located at a different URL. Future requests should continue using the original URL.

Temporary redirects for A/B testing, maintenance pages, or country-specific routing.
303

See Other

The response to the request can be found at another URI using a GET method.

Used after a POST request to redirect the client to a confirmation page using GET.
304

Not Modified

The resource has not been modified since the version specified by the request headers.

Browser caching: the server tells the client to use its cached copy, saving bandwidth.
307

Temporary Redirect

The request should be repeated with another URI, but future requests should still use the original URI. The method must not change.

Like 302 but guarantees the HTTP method is preserved (POST stays POST).
308

Permanent Redirect

The resource has been permanently moved. The method and body must not change.

Like 301 but guarantees the HTTP method is preserved. Used for API endpoint migrations.
400

Bad Request

The server cannot process the request due to a client error such as malformed syntax.

Returned when request validation fails: missing required fields, invalid JSON, wrong data types.
401

Unauthorized

The request requires user authentication. The client must authenticate itself to get the requested response.

Returned when an API request is missing a valid authentication token or API key.
402

Payment Required

Reserved for future use. Originally intended for digital payment systems.

Some APIs use this to indicate a paid subscription is required to access the resource.
403

Forbidden

The server understood the request but refuses to authorize it.

User is authenticated but lacks permissions. E.g., a regular user trying to access an admin endpoint.
404

Not Found

The server cannot find the requested resource. The URL is not recognized.

The most common error: broken links, deleted pages, mistyped URLs, or missing API endpoints.
405

Method Not Allowed

The request method is not supported for the requested resource.

Sending a DELETE request to an endpoint that only accepts GET and POST.
406

Not Acceptable

The server cannot produce a response matching the list of acceptable values defined in the request headers.

Content negotiation fails: client requests XML but the server can only produce JSON.
407

Proxy Authentication Required

The client must first authenticate itself with the proxy.

Corporate proxy servers that require authentication before allowing internet access.
408

Request Timeout

The server timed out waiting for the request.

Slow client connections or the client took too long to send the full request body.
409

Conflict

The request conflicts with the current state of the server.

Creating a user with an email that already exists, or updating a resource that has been modified by another user.
410

Gone

The resource is no longer available and will not be available again.

Permanently deleted content. Unlike 404, this tells search engines to remove the page from their index.
411

Length Required

The request did not specify the length of its content as required by the server.

Server requires a Content-Length header for POST/PUT requests.
412

Precondition Failed

The server does not meet one of the preconditions specified in the request headers.

Conditional requests using If-Match or If-Unmodified-Since headers for optimistic concurrency.
413

Payload Too Large

The request entity is larger than limits defined by the server.

File upload exceeds the server maximum size limit. Common with image/video uploads.
414

URI Too Long

The URI requested by the client is longer than the server is willing to interpret.

Extremely long query strings from complex search filters or improperly encoded data.
415

Unsupported Media Type

The media format of the requested data is not supported by the server.

Sending form data to an endpoint that expects JSON, or uploading an unsupported file format.
416

Range Not Satisfiable

The range specified in the Range header cannot be fulfilled.

Requesting byte range beyond the end of a file during a partial download.
417

Expectation Failed

The server cannot meet the requirements of the Expect request-header field.

The server cannot satisfy the Expect: 100-continue header.
418

I'm a Teapot

The server refuses to brew coffee because it is, permanently, a teapot. Defined in RFC 2324.

An April Fools joke RFC that became a beloved easter egg in many web frameworks.
422

Unprocessable Entity

The request was well-formed but was unable to be followed due to semantic errors.

Validation errors: correct JSON syntax but invalid field values like negative age or invalid email.
423

Locked

The resource being accessed is locked.

WebDAV: a file is locked by another user and cannot be modified.
424

Failed Dependency

The request failed because it depended on another request that also failed.

WebDAV batch operations where one step fails causing subsequent steps to fail.
425

Too Early

The server is unwilling to risk processing a request that might be replayed.

TLS 1.3 early data (0-RTT) requests that could be vulnerable to replay attacks.
426

Upgrade Required

The server refuses to perform the request using the current protocol.

Server requires the client to switch to TLS/1.0 or upgrade to HTTP/2.
428

Precondition Required

The server requires the request to be conditional.

Server requires If-Match headers to prevent lost update problems in concurrent editing.
429

Too Many Requests

The user has sent too many requests in a given amount of time (rate limiting).

API rate limiting: typically returns a Retry-After header indicating when to try again.
431

Request Header Fields Too Large

The server is unwilling to process the request because its header fields are too large.

Oversized cookies or too many headers. Often fixed by clearing browser cookies.
451

Unavailable For Legal Reasons

The resource is unavailable due to legal demands such as censorship or government-mandated blocking.

Content blocked due to court orders, DMCA takedowns, or regional legal restrictions.
500

Internal Server Error

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

Unhandled exceptions, null pointer errors, database failures, or misconfigured servers.
501

Not Implemented

The server does not support the functionality required to fulfill the request.

Server does not recognize the request method or lacks ability to fulfill it. E.g., PATCH not implemented.
502

Bad Gateway

The server acting as a gateway received an invalid response from the upstream server.

Nginx/load balancer cannot get a valid response from the application server behind it.
503

Service Unavailable

The server is not ready to handle the request, usually due to maintenance or overload.

Deployment in progress, server overloaded, or scheduled maintenance window.
504

Gateway Timeout

The server acting as a gateway did not receive a timely response from the upstream server.

Slow database queries or external API calls causing the reverse proxy to time out.
505

HTTP Version Not Supported

The server does not support the HTTP protocol version used in the request.

Client sends HTTP/3 request to a server that only supports HTTP/1.1 and HTTP/2.
506

Variant Also Negotiates

The server has an internal configuration error during content negotiation.

Circular reference in transparent content negotiation configuration.
507

Insufficient Storage

The server is unable to store the representation needed to complete the request.

WebDAV: disk space is full and the server cannot save the uploaded file.
508

Loop Detected

The server detected an infinite loop while processing the request.

WebDAV: a PROPFIND request with Depth: infinity encounters a binding loop.
510

Not Extended

Further extensions to the request are required for the server to fulfill it.

The server requires a specific HTTP extension that the client did not include.
511

Network Authentication Required

The client needs to authenticate to gain network access.

Captive portals in airports, hotels, and coffee shops that require login before internet access.
Advertisement

Related Tools

Advertisement

Frequently Asked Questions

What are HTTP status codes?
HTTP status codes are three-digit numbers returned by a web server in response to a client request. They indicate whether the request was successful, redirected, or resulted in an error. The first digit defines the category: 1xx for informational, 2xx for success, 3xx for redirection, 4xx for client errors, and 5xx for server errors.
What is the difference between 301 and 302 redirects?
A 301 redirect indicates a permanent move — the resource has been permanently relocated to a new URL and search engines should update their index. A 302 redirect indicates a temporary move — the resource is temporarily at a different URL but will return to the original. For SEO, 301 redirects pass link equity to the new URL while 302 redirects do not.
What does HTTP 404 mean?
HTTP 404 Not Found means the server cannot find the requested resource. This typically happens when a URL is mistyped, a page has been deleted, or a link is broken. Custom 404 pages should help users navigate to useful content rather than showing a generic error.
What is the difference between 401 and 403?
HTTP 401 Unauthorized means the request lacks valid authentication credentials — the user needs to log in or provide a valid API key. HTTP 403 Forbidden means the server understood the request but refuses to authorize it — the user is authenticated but does not have permission to access the resource.
What causes a 500 Internal Server Error?
A 500 Internal Server Error indicates an unexpected condition on the server that prevented it from fulfilling the request. Common causes include unhandled exceptions in application code, misconfigured server settings, database connection failures, or exhausted server resources like memory or disk space.
What is HTTP 429 Too Many Requests?
HTTP 429 indicates the user has sent too many requests in a given time period (rate limiting). The response usually includes a Retry-After header indicating how long to wait before making another request. This is commonly used by APIs to prevent abuse and ensure fair usage across all clients.
What is the difference between 200 and 204?
HTTP 200 OK means the request succeeded and the response body contains the requested data. HTTP 204 No Content means the request succeeded but there is no content to return in the response body. 204 is commonly used for DELETE operations or form submissions where no response body is needed.
When should I use HTTP 201 vs 200?
HTTP 201 Created should be used when a new resource has been successfully created as a result of the request, typically for POST requests that create database records. HTTP 200 OK is used for general successful requests like GET, PUT, or PATCH operations that read or update existing resources.

Complete HTTP Status Code Reference Guide

HTTP status codes are a fundamental part of how the web works. Every time your browser requests a page, downloads a file, or submits a form, the web server responds with a three-digit status code that tells the client what happened. Understanding these codes is essential for web developers, API designers, system administrators, and anyone who builds or maintains web applications.

Our free HTTP status code reference provides a complete, searchable database of all standard HTTP response codes defined by the IETF in RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC 6585, and RFC 8470. Each status code includes its official name, a detailed description of what it means, and common real-world use cases to help you understand when and why each code is returned.

Understanding HTTP Status Code Categories

1xx Informational responses indicate that the server has received the request and is continuing to process it. These are rarely seen by end users but are important for protocols like WebSocket upgrades (101 Switching Protocols) and large file uploads (100 Continue). The 100 Continue status is particularly useful for clients sending large request bodies, as it allows the server to reject the request before the full body is transmitted.

2xx Success responses confirm that the request was successfully received, understood, and accepted. The most common is 200 OK for standard successful requests. Other important codes include 201 Created for new resource creation, 204 No Content for successful operations with no response body, and 206 Partial Content for range requests used in video streaming and resumable downloads.

3xx Redirection responses tell the client that further action is needed to complete the request. 301 Moved Permanently and 302 Found are the most common, used for URL redirections. 304 Not Modified is crucial for caching efficiency, telling the browser to use its cached copy rather than downloading the resource again. Understanding the difference between permanent and temporary redirects is critical for SEO.

4xx Client error responses indicate that the request contains bad syntax or cannot be fulfilled due to a problem on the client side. 400 Bad Request covers malformed syntax, 401 Unauthorized requires authentication, 403 Forbidden denies access despite authentication, and 404 Not Found indicates a missing resource. The 429 Too Many Requests code is increasingly important for rate-limited APIs and DDoS protection.

5xx Server error responses indicate that the server failed to fulfill a valid request. 500 Internal Server Error is the generic catch-all for unexpected server failures. 502 Bad Gateway indicates an upstream server returned an invalid response, commonly seen with reverse proxies. 503 Service Unavailable means the server is temporarily overloaded or under maintenance, and 504 Gateway Timeout occurs when an upstream server does not respond in time.

HTTP Status Codes for API Development

When designing RESTful APIs, proper use of HTTP status codes is essential for creating intuitive and maintainable interfaces. A well-designed API uses 200 for successful GET requests, 201 for successful POST operations that create resources, 204 for successful DELETE operations, 400 for validation errors with descriptive error messages, 401 for missing or invalid authentication tokens, 403 for insufficient permissions, 404 for resources that do not exist, 409 for conflicts like duplicate entries, and 422 for semantically invalid request data.

Rate limiting should return 429 with a Retry-After header, and server errors should return 500 with a correlation ID for debugging. Consistent status code usage across your API makes it predictable for consumers and simplifies error handling in client applications. Always pair status codes with descriptive error response bodies that help developers understand what went wrong and how to fix it.

Why Use Our HTTP Status Code Reference?

Instant search. Filter the entire list of HTTP status codes by typing a code number, name, or keyword. Find the exact code you need in seconds without scrolling through documentation. The search works across code numbers, names, and descriptions for maximum flexibility.

Category filtering. Focus on specific categories like client errors (4xx) or server errors (5xx) with one click. This is useful when you are debugging a specific type of issue or learning about a particular category of responses.

Real-world use cases. Every status code includes practical examples of when and why it is used, going beyond the RFC specifications to explain how these codes are used in modern web applications, APIs, and microservice architectures.

Always available. This reference works entirely in your browser with no server requests needed. Bookmark it and use it even when you are offline. No accounts, no ads blocking your view, just instant access to the information you need.

Advertisement