1xx Informational
The request was received and the exchange is still going. Browsers handle these for you and rarely show them.
The server has received the request headers and the client can go ahead and send the body.
- Common causes
- A client sent Expect: 100-continue before uploading a large body, to check the server would accept it first.
- What to do
- Nothing. If uploads stall at this point, a proxy in between may not support Expect: 100-continue; disable it in the client.
The server agrees to change protocol on this connection, as the client asked in its Upgrade header.
- Common causes
- Opening a WebSocket, or upgrading a connection to HTTP/2 over plain text.
- What to do
- Nothing when it works. If WebSockets fail behind a proxy, make sure the proxy passes the Upgrade and Connection headers.
A WebDAV server has accepted the request and is still working on it, so the client should not time out yet.
- Common causes
- Long WebDAV operations such as copying a large folder.
- What to do
- Nothing. The code is deprecated and few servers send it now.
The server sends some headers, usually Link preload hints, before the final response is ready.
- Common causes
- A server or CDN telling the browser to start fetching CSS, fonts or scripts while the page is still being generated.
- What to do
- Nothing. It is a speed feature; the final status code follows.
2xx Success
The request worked.
The request succeeded and the response carries the result.
- Common causes
- A normal page load or API call.
- What to do
- Nothing. For an API that returns an error message with 200, the server is misreporting the result and the client has to read the body to know.
The request succeeded and created something new, usually named in the Location header.
- Common causes
- A POST or PUT to an API that creates a record.
- What to do
- Read the Location header for the address of the new resource.
The request was accepted for processing, but the work is not finished yet.
- Common causes
- Queued jobs: video encoding, bulk imports, report generation.
- What to do
- Poll the status address the API gives you, or wait for its webhook.
The request succeeded, but a proxy changed the response from what the origin server sent.
- Common causes
- A transforming proxy that rewrote headers or content.
- What to do
- Nothing in most cases. Fetch from the origin directly if you need the unmodified response.
The request succeeded and there is deliberately no body.
- Common causes
- A DELETE, a saved form with nothing to show, or an analytics beacon.
- What to do
- Nothing. Do not try to parse a body; there is none.
The request succeeded and the client should reset the form or view that sent it.
- Common causes
- Rarely used; meant for data entry forms.
- What to do
- Clear the form.
The server is sending only the part of the file the client asked for in its Range header.
- Common causes
- Video streaming, resumed downloads and download managers that fetch in pieces.
- What to do
- Nothing. If a resumed download is corrupt, the file probably changed on the server between requests.
A WebDAV response that carries several separate status codes in its XML body.
- Common causes
- WebDAV operations that touch many files at once.
- What to do
- Read each status in the body; some parts may have failed.
Used inside a WebDAV Multi-Status response so the same member is not listed twice.
- Common causes
- WebDAV bindings that make a collection appear more than once.
- What to do
- Nothing.
The server applied delta encoding and is returning the changes rather than the whole resource.
- Common causes
- Very rare: clients that support HTTP delta encoding (RFC 3229).
- What to do
- Nothing.
3xx Redirection
The client has to go somewhere else, or use its cached copy.
There are several versions of the resource and the client or user should choose one.
- Common causes
- Rare: content negotiation with no clear best match.
- What to do
- Pick one of the options listed in the response.
The resource has a new permanent address, given in the Location header.
- Common causes
- A site moved to HTTPS or a new domain, or a page was renamed.
- What to do
- Update links and bookmarks. Search engines pass ranking to the new address. Browsers cache 301s hard, so test redirects with 302 first. Browsers may change a POST to GET when following it; use 308 to keep the method.
The resource is temporarily at another address.
- Common causes
- Login redirects, A/B tests, short lived campaign links.
- What to do
- Nothing for visitors. If the move is permanent, change it to 301 so search engines update.
Fetch the result from another address with GET.
- Common causes
- The standard reply after a form POST, so refreshing the next page does not resubmit the form.
- What to do
- Follow the Location header with a GET.
The cached copy the client already has is still current, so no body is sent.
- Common causes
- The browser asked with If-None-Match or If-Modified-Since and nothing changed.
- What to do
- Nothing; this is caching working. If users see stale content, the server is sending the same ETag or date after changes.
Deprecated. It once told the client to use a proxy.
- Common causes
- Old servers only.
- What to do
- Ignore. Browsers do not act on it, for security reasons.
Like 302, but the client must repeat the same method and body at the new address.
- Common causes
- Redirecting an API POST, or HSTS sending a browser from http to https.
- What to do
- Follow the Location header with the same method.
Like 301, but the client must repeat the same method and body.
- Common causes
- An API endpoint that moved for good.
- What to do
- Update the address in your code.
4xx Client error
Something is wrong with the request: the address, the login, the data or the rate.
The server could not understand the request.
- Common causes
- Malformed JSON, a missing required field, an oversized or corrupt cookie, or a bad URL.
- What to do
- Check the request body and parameters against the API documentation. On a website, clearing the site's cookies often fixes it.
Authentication is needed and was missing or wrong.
- Common causes
- No login, an expired session, a missing or invalid API key or token.
- What to do
- Sign in again or refresh the token. Despite the name it means unauthenticated; for a valid login without permission the code is 403.
Reserved for future use, now used by some APIs to say payment is needed.
- Common causes
- An unpaid account, an expired plan or a used up quota on a paid API.
- What to do
- Check billing on the service's account page.
The server understood the request but refuses it.
- Common causes
- Missing permissions, a firewall or bot rule blocking you, a folder without an index page, or file permissions the web server cannot read.
- What to do
- If it is your site, check file permissions (644 for files, 755 for folders), .htaccess rules and the firewall. As a visitor, try without a VPN, since some sites block their addresses.
Nothing exists at this address, or the server will not say that it does.
- Common causes
- A typo, a deleted or moved page without a redirect, or a broken link.
- What to do
- Check the address. Site owners should redirect moved pages with 301 and fix internal links.
The address exists but does not accept this method, such as POST where only GET works.
- Common causes
- Calling an API endpoint with the wrong method, or a form posting to a static page.
- What to do
- Use a method listed in the Allow header of the response.
The server cannot produce a response in any format the client's Accept headers allow.
- Common causes
- An API client asking for XML from a JSON only API, or a security module reacting to unusual headers.
- What to do
- Loosen the Accept header, for example to */*.
Like 401, but the proxy in between needs the login.
- Common causes
- A corporate proxy that needs your credentials.
- What to do
- Configure the proxy username and password in the browser or tool.
The server gave up waiting for the client to finish sending the request.
- Common causes
- A slow or dropped connection, or a browser keeping an idle connection open too long.
- What to do
- Retry. Persistent timeouts point to the network or an upload that is too slow.
The request conflicts with the current state of the resource.
- Common causes
- Editing a record someone else changed, creating something that already exists, or a version mismatch.
- What to do
- Reload the latest version, merge your change and try again.
The resource was deliberately removed and will not come back.
- Common causes
- Expired offers, deleted accounts or retired API versions.
- What to do
- Remove links to it. Search engines drop a 410 page faster than a 404.
The server needs a Content-Length header and the request had none.
- Common causes
- Some clients sending a POST body without stating its length.
- What to do
- Send the Content-Length header.
A condition in the request headers, such as If-Match, was not met.
- Common causes
- Optimistic locking: the resource changed since you last fetched it.
- What to do
- Fetch the current version and its ETag, then retry.
The request body is bigger than the server allows.
- Common causes
- Uploading a file above the limit, often nginx client_max_body_size or PHP upload_max_filesize.
- What to do
- Upload a smaller file, or raise the limit on the server.
The address is longer than the server will process.
- Common causes
- Huge query strings, often from a form using GET for lots of data, or a redirect loop that keeps adding parameters.
- What to do
- Send the data with POST in the body instead.
The server does not accept the format of the request body.
- Common causes
- Sending form data to an API that expects JSON, or a missing or wrong Content-Type header.
- What to do
- Set Content-Type to what the API expects, such as application/json.
The byte range asked for is outside the file.
- Common causes
- Resuming a download of a file that has since changed or shrunk.
- What to do
- Restart the download from the beginning.
The server cannot meet the Expect header in the request.
- Common causes
- A server or proxy that does not support Expect: 100-continue.
- What to do
- Send the request without the Expect header.
An April Fools' joke from RFC 2324: a teapot refusing to brew coffee. It is reserved, not a real status.
- Common causes
- Some sites and APIs return it on purpose to turn away bots.
- What to do
- Nothing, unless a service uses it to block you; then treat it like 403.
The request reached a server that cannot answer for this domain.
- Common causes
- HTTP/2 connection reuse across domains that share an address but not a certificate, or a CDN routing problem.
- What to do
- Retry on a new connection. Site owners should check that the certificate and server names match.
The request is well formed but its data fails validation.
- Common causes
- An invalid email address, a missing required field or a value outside the allowed range in an API call.
- What to do
- Read the error details in the response body and correct the data.
A WebDAV resource is locked.
- Common causes
- Another user or program has the file open for editing.
- What to do
- Wait for the lock to be released.
A WebDAV action failed because another action it depended on failed.
- Common causes
- Batch WebDAV operations.
- What to do
- Fix the first failure in the batch.
The server will not risk processing a request that might be replayed.
- Common causes
- TLS 1.3 early data sent before the handshake completed.
- What to do
- Retry after the connection is fully set up; clients usually do this automatically.
The server will only answer over a different protocol, named in the Upgrade header.
- Common causes
- A service that requires a newer TLS or HTTP version.
- What to do
- Update the client or switch to the protocol the server names.
The server requires the request to be conditional, such as with If-Match.
- Common causes
- APIs that protect against lost updates.
- What to do
- Fetch the resource, then send its ETag in If-Match.
The client sent too many requests in a given time and is being rate limited.
- Common causes
- Scripts or apps calling an API in a tight loop, scrapers, or many users behind one shared address.
- What to do
- Slow down and retry after the time in the Retry-After header, with exponential backoff in code.
The headers are too big, either one header or all of them together.
- Common causes
- Too many or oversized cookies for the domain.
- What to do
- Clear the site's cookies. Developers should keep cookies small.
The resource is blocked for legal reasons, such as a court order or sanctions.
- Common causes
- Content withheld in some countries, or a legal takedown.
- What to do
- Nothing a visitor can fix. The response should say who demanded the block.
5xx Server error
The request may be fine but the server failed to handle it.
Something went wrong on the server and it has no more specific code to give.
- Common causes
- A bug or crash in the application, a PHP fatal error, a bad .htaccess rule, or a database error.
- What to do
- Visitors can only retry later. Site owners should check the server and application error logs, which name the actual failure.
The server does not support the method or feature the request needs.
- Common causes
- An unusual HTTP method sent to a basic server.
- What to do
- Use a method the server supports.
A proxy, load balancer or CDN got an invalid response from the server behind it.
- Common causes
- The application server (PHP-FPM, Node, Gunicorn) crashed, restarted or refused the connection.
- What to do
- Retry in a minute. Site owners should check that the backend service is running and look at the proxy's error log.
The server cannot handle the request right now.
- Common causes
- Maintenance, overload or every backend being down.
- What to do
- Retry later, after the Retry-After time if given. A planned outage should return 503 so search engines do not drop the pages.
A proxy or CDN waited too long for the server behind it.
- Common causes
- Slow database queries, long running scripts or an overloaded backend.
- What to do
- Retry. Site owners should find the slow request; raising the proxy timeout only hides it.
The server does not support the HTTP version used in the request.
- Common causes
- Very old or very new clients meeting a strict server.
- What to do
- Use HTTP/1.1, which every server supports.
The server's content negotiation is misconfigured and loops.
- Common causes
- A server configuration mistake.
- What to do
- Site owners should fix the negotiation settings.
The server has no space left to store what the request needs.
- Common causes
- A full disk on a WebDAV or file storage server.
- What to do
- Free up space on the server.
The server found an infinite loop while processing a WebDAV request.
- Common causes
- Bindings that refer back to themselves.
- What to do
- Fix the loop in the WebDAV structure.
The request needs an HTTP extension the server does not have. The code is now obsolete.
- Common causes
- Very rare.
- What to do
- Nothing.
You need to sign in to the network before you can reach the internet.
- Common causes
- Hotel, airport or café Wi-Fi with a login page (a captive portal).
- What to do
- Open any http page in the browser to get the login page, then sign in.
No status code matches that. Try a number or a single word.