Showing 70 of 70 status codes
The server has received the request headers and the client should go ahead and send the body.
Used with the Expect: 100-continue header so a client can check the server will accept a large upload before sending it. HTTP libraries handle it for you.
The server is switching to the protocol the client asked for in the Upgrade header.
Most commonly seen when a connection is upgraded to WebSocket. If a WebSocket connection fails, check that your proxy passes the Upgrade and Connection headers through.
(WebDAV) The server has accepted the request and is still working on it.
Deprecated and almost never seen. It only existed to stop WebDAV clients timing out on slow operations.
The server sends preliminary Link headers so the browser can start preloading resources before the final response is ready.
Speeds up page loads by preloading CSS and JavaScript while the server is still building the page. Supported by modern browsers and CDNs.
The request succeeded and the response contains the result.
The default success code. For GET the body is the resource; for POST it's the result of the action. Consider 201 or 204 when they describe the outcome more precisely.
The request succeeded and a new resource was created.
Return it from a POST (or PUT) that creates something, with a Location header pointing at the new resource.
The request was accepted for processing, but processing hasn't finished.
Use it for asynchronous work such as queued jobs, and give the client a way to check progress, like a status URL. It doesn't promise the work will succeed.
The request succeeded, but a proxy has modified the response from the origin server.
Rare in practice. Treat it like a 200.
The request succeeded and there is no body to return.
Common for DELETE, and for PUT or PATCH where the client already has the data. The response must not include a body.
The request succeeded, and the client should reset the view that sent it, for example by clearing a form.
Rare. The response must not include a body.
The server is returning only part of the resource, as requested by a Range header.
Powers resumable downloads and video seeking. If you see it unexpectedly, a client or CDN is making range requests.
(WebDAV) The body contains several separate status codes, one for each of multiple operations.
Seen in WebDAV and some batch APIs. Check each individual status in the body rather than relying on the overall 207.
(WebDAV) Members of a binding were already listed earlier in the response and aren't repeated.
WebDAV-only and almost never seen.
The server fulfilled a GET request using instance manipulations (delta encoding) applied to the current instance.
Very rare. It's part of an HTTP delta-encoding extension that saw little adoption.
The resource has several representations and the client should pick one.
Rarely used because there's no standard way to make the choice. Prefer content negotiation or an explicit redirect.
The resource has permanently moved to the URL in the Location header.
Use it for permanent URL changes. Browsers and search engines cache it and pass ranking signals to the new URL. Clients may change POST to GET when following it; use 308 to keep the method.
The resource is temporarily at a different URL, given in the Location header.
Use it for temporary redirects. Clients may change POST to GET; use 307 if the method must be preserved. Search engines keep the original URL indexed.
The response is at another URL, and the client should fetch it with GET.
The standard way to redirect after a POST so refreshing the page doesn't resubmit the form (Post/Redirect/Get).
The cached copy is still valid, so no body is sent.
The response to a conditional request (If-None-Match or If-Modified-Since) when nothing has changed. It saves bandwidth and is not an error.
The requested resource must be accessed through a proxy.
Deprecated for security reasons and ignored by browsers. Don't use it.
Temporary redirect to the Location URL, and the client must repeat the same method and body.
Like 302, but it guarantees a POST stays a POST. The right choice for temporary redirects of API calls.
Permanent redirect to the Location URL, and the client must repeat the same method and body.
Like 301, but it guarantees the method is preserved. The right choice for permanently moving an API endpoint.
The server can't process the request because it looks malformed.
The request lacks valid authentication credentials. Despite the name, this is about authentication, not permission.
Reserved for digital payment systems, with no standard usage.
The server understood the request but refuses to authorize it.
The server can't find the requested resource.
The HTTP method isn't supported for this resource.
The server can't produce a response matching the client's Accept headers.
Like 401, but the client must first authenticate with a proxy.
The server timed out waiting for the client to finish sending the request.
The request conflicts with the current state of the resource.
The resource used to exist and has been permanently removed.
The server requires a Content-Length header.
A condition in the request headers (such as If-Match or If-Unmodified-Since) evaluated to false.
The request body is larger than the server allows. (Formerly called "Payload Too Large".)
The URL is longer than the server is willing to process.
The server doesn't accept the request's Content-Type.
The Range header asked for a part of the resource that doesn't exist.
The server can't meet the requirements of the Expect header.
A joke status from an April Fools' RFC (RFC 2324): the server is a teapot and refuses to brew coffee.
The request was sent to a server that can't produce a response for that host.
The request is well-formed, but its content is semantically invalid.
(WebDAV) The resource being accessed is locked.
(WebDAV) The request failed because an earlier request it depended on failed.
The server won't process a request that might be replayed.
The server refuses the request using the current protocol and requires the client to upgrade.
The server requires the request to be conditional.
The client has sent too many requests in a given time (rate limiting).
The request headers, or one header, are too large.
The resource is blocked for legal reasons, such as a court order or censorship.
The server hit an unexpected condition and couldn't complete the request.
The server doesn't support the functionality required to fulfil the request.
A gateway or proxy received an invalid response from the upstream server.
The server can't handle the request right now, typically because it's overloaded or down for maintenance.
A gateway or proxy didn't get a response from the upstream server in time.
The server doesn't support the HTTP version used in the request.
A server misconfiguration in transparent content negotiation.
(WebDAV) The server can't store what's needed to complete the request.
(WebDAV) The server detected an infinite loop while processing the request.
The server requires further extensions to the request in order to fulfil it.
The client must authenticate to gain network access.
Not part of the HTTP standard, but common enough (nginx, Cloudflare) that you'll run into them.
(nginx) The client closed the connection before the server sent a response.
(Cloudflare) The origin server returned an empty, unknown, or unexpected response to Cloudflare.
(Cloudflare) The origin server refused Cloudflare's connection.
(Cloudflare) Cloudflare couldn't complete a TCP connection to the origin server in time.
(Cloudflare) Cloudflare can't reach the origin server, often because of a routing or DNS problem.
(Cloudflare) Cloudflare connected to the origin, but it didn't reply with an HTTP response in time.
(Cloudflare) Cloudflare couldn't establish an SSL/TLS handshake with the origin server.
(Cloudflare) Cloudflare couldn't validate the origin server's SSL certificate.
Every HTTP status code in one searchable list, from 100 Continue to 511 Network Authentication Required, plus the unofficial nginx and Cloudflare codes (like 499 and 522) you'll meet in real logs. Each error code has a one-line common cause and a one-line fix, and every code has its own link, so you can share /tools/http-status-codes#404 directly. The most-searched errors (400, 401, 403, 404, 429, 500, 502, 503 and 504) also have a full guide with causes, step-by-step fixes and FAQs.
The first digit tells you the class. 1xx codes are informational, 2xx mean success, 3xx are redirects, 4xx mean the client made a mistake (bad request, not found, not authorised), and 5xx mean the server failed to handle a valid request.
401 Unauthorized means you haven't authenticated: the server doesn't know who you are, so log in or send valid credentials. 403 Forbidden means the server knows who you are but you're not allowed to access the resource, so logging in again won't help.
301 is a permanent redirect: browsers and search engines cache it and treat the new URL as the real one. 302 is temporary: the original URL stays the canonical one. If the redirect must keep the request method (for example POST), use 308 (permanent) or 307 (temporary).
All three are server-side. 502 Bad Gateway: a proxy got an invalid response from the upstream server. 503 Service Unavailable: the server is overloaded or in maintenance, usually temporarily. 504 Gateway Timeout: the proxy gave up waiting for the upstream server to respond.
Use 200 for successful reads, 201 for created resources, 204 for success with no body, 400 or 422 for invalid input, 401 or 403 for auth problems, 404 for missing resources, 429 for rate limiting, and 500 for unexpected server errors. Precise codes make an API much easier to debug.
They're defined by specific software rather than the HTTP standard. 499 is nginx's code for a client that closed the connection early, and the 52x series (520 to 526) are Cloudflare's codes for problems reaching your origin server.