Complete guide to HTTP response status codes. Browse informational, success, redirection, client error, and server error codes with troubleshooting guides.
The server failed to fulfill a valid request. These indicate problems on the server side — crashes, overload, misconfigurations, or upstream failures.
The server encountered an unexpected condition that prevented it from fulfilling the request.
The server does not support the functionality required to fulfill the request.
The server received an invalid response from the upstream server.
The server is temporarily unable to handle the request due to overload or maintenance.
The upstream server did not respond within the gateway's timeout period.
The server does not support the HTTP protocol version used in the request.
The server has a circular reference in transparent content negotiation.
The server cannot store the representation needed to complete the request (WebDAV).
The server detected an infinite loop while processing the request (WebDAV).
The request requires further extensions that the server does not support.
The client must authenticate to gain network access (captive portal).
The request contains an error on the client side — bad syntax, missing authentication, forbidden access, or a resource that does not exist.
The server cannot process the request due to a client-side error.
Authentication is required and has not been provided or is invalid.
Payment is required to access this resource (reserved for future use).
The server understood the request but refuses to authorize it.
The requested resource could not be found on the server.
The HTTP method used is not supported for this resource.
The server cannot produce a response matching the client's Accept headers.
The client must first authenticate with the proxy server.
The server timed out waiting for the client to complete the request.
The request conflicts with the current state of the resource.
The resource has been permanently removed and will not return.
The server requires a Content-Length header in the request.
A precondition in the request headers evaluated to false.
The request body exceeds the server's maximum allowed size.
The request URI exceeds the server's maximum allowed length.
The server does not support the media type of the request body.
The requested byte range is not available for the resource.
The server cannot meet the requirements of the Expect header.
A humorous response defined in the Hyper Text Coffee Pot Control Protocol.
The request was directed at a server that cannot produce a response.
The request is well-formed but contains semantic errors.
The resource is locked and cannot be modified (WebDAV).
The request failed because it depends on another request that failed (WebDAV).
The server refuses to process a request that might be replayed.
The server requires the client to upgrade to a different protocol.
The server requires the request to include conditional headers.
The client has sent too many requests and is being rate limited.
The request headers are too large for the server to process.
The client must take additional action to complete the request, usually following a redirect to a different URL. Important for SEO and URL management.
The request has multiple possible responses and the client should choose one.
The resource has been permanently moved to a new URL.
The resource is temporarily located at a different URL.
The response to the request can be found at a different URI using GET.
The resource has not changed since the last request; use the cached version.
The requested resource must be accessed through the specified proxy (deprecated).
The resource is temporarily at a different URL; the request method must not change.
The resource has permanently moved; the request method must not change.
Status codes used by specific web servers that are not part of the HTTP specification. These are commonly seen in Nginx logs and error pages.
The request was successfully received, understood, and accepted by the server. These codes confirm the operation completed as expected.
The request succeeded and the server returned the requested resource.
The request succeeded and a new resource was created on the server.
The request was accepted for processing but has not been completed yet.
The response was modified by a transforming proxy and differs from the origin.
The request succeeded but the server has no content to return.
The request succeeded and the client should reset the document view.
The server is delivering only part of the resource due to a Range header.
Interim responses indicating the server received the request and the client should continue. These are rarely seen in browser traffic but are used in protocol-level communication.
The server received the request headers and the client should proceed to send the body.
The server is switching to a different protocol as requested by the client.
The server is processing the request but has not yet completed it (WebDAV).
The server sends preliminary headers to the client before the final response.
Every time a browser loads a page, it sends an HTTP request to a server and receives a response. The status code in that response is the first thing the client checks to understand what happened:
The browser resolves the domain name to an IP address using DNS. If this fails, no HTTP request is made at all — you will see a DNS_PROBE_FINISHED_NXDOMAIN error instead of a status code.
The browser opens a TCP connection to the server on port 80 (HTTP) or 443 (HTTPS). Connection refused or timeout errors occur here before any status code is returned.
For HTTPS requests, the browser and server negotiate encryption. SSL/TLS errors occur at this stage, before any HTTP status code is exchanged.
The browser sends the request method (GET, POST, etc.), headers, and body. The server processes the request and determines the appropriate status code.
The server runs application logic, queries databases, checks authentication, and builds a response. Errors during this phase typically result in 4xx or 5xx status codes.
The server sends back a status code, response headers, and body. The status code tells the client whether to display content (2xx), follow a redirect (3xx), or show an error (4xx/5xx).
Status codes only appear at step 6 — if the connection fails before the HTTP layer, you will see browser-level or network errors instead.
HTTP status codes are grouped by their first digit into five classes. Each class tells you the general outcome of the request before you look at the specific code:
The server acknowledges the request and tells the client to continue or wait. These are provisional responses used during protocol negotiation and are rarely visible to end users.
The request was received, understood, and accepted. The most common is 200 OK. Other codes like 201 Created and 204 No Content provide more specific success context for API consumers.
The resource is available at a different location. The client (browser or HTTP client) should follow the redirect. The distinction between codes matters for SEO — 301 transfers link equity, 302 does not.
The request has a problem on the client side. The URL may be wrong (404), authentication may be missing (401), or the request body may be malformed (400). The client needs to fix the request before retrying.
The server failed to process a valid request. This means the problem is on the server side — application crashes (500), upstream failures (502), service overload (503), or timeout (504). These require server-side investigation and cannot be fixed by the client.
Not every non-200 status code is a problem. Some are expected and healthy parts of HTTP communication:
Monitor your error rates over time. A sudden spike in 5xx errors or 404s after a deployment is a strong signal that something broke. Occasional 4xx errors from bots and scanners are normal background noise.