The server has received the request headers and the client may send the body. Used when a client sends Expect: 100-continue to check that a large upload will be accepted first.
Specification: RFC 9110 §15.2.1
HTTP Status Codes
Look up every HTTP status code with its meaning, common causes and fixes. Search by number or keyword in English or Chinese.
Type a number (like 404 or 5xx) or a keyword
63 status codes
1xx Informational
The server agrees to the client’s Upgrade request and switches protocols, most often from HTTP/1.1 to WebSocket.
Specification: RFC 9110 §15.2.2
An interim WebDAV response saying the server is still working on the request, so the client does not time out. Rarely used today.
Later WebDAV specifications (RFC 4918) no longer define it.
Specification: RFC 2518 §10.1
Sends Link headers before the final response so the browser can start preloading CSS and fonts or preconnecting early, speeding up page loads.
Specification: RFC 8297 §2
2xx Success
The request succeeded. For GET the body holds the resource; for POST it describes the result. The most common status code.
Specification: RFC 9110 §15.3.1
The request succeeded and created a new resource, typically after POST or PUT. The Location header points to the new resource.
Specification: RFC 9110 §15.3.2
The request was accepted but not processed yet (for example, queued as a background job). It may still succeed or fail later.
Specification: RFC 9110 §15.3.3
The request succeeded, but a proxy in between modified the content, so it is not exactly what the origin server sent.
Specification: RFC 9110 §15.3.4
The request succeeded and there is nothing to send back. Common for DELETE, saving settings and CORS preflight (OPTIONS) responses.
Specification: RFC 9110 §15.3.5
The request succeeded; the client should reset its view, such as clearing a submitted form. Rarely used in practice.
Specification: RFC 9110 §15.3.6
The server sends only the part requested with a Range header. Used for resumable downloads and seeking in video.
Specification: RFC 9110 §15.3.7
WebDAV: when one request acts on several resources, an XML body lists the status of each.
Specification: RFC 4918 §11.1
WebDAV: the resource was already listed earlier in a Multi-Status response, so it is not repeated.
Specification: RFC 5842 §7.1
The response is the result of instance manipulations, such as a delta encoding that sends only what changed. Very rarely used.
Specification: RFC 3229 §10.4.1
3xx Redirection
The resource has several representations (such as languages or formats) and the client should choose one. Rarely used.
Specification: RFC 9110 §15.4.1
The resource has moved for good to the URL in the Location header. Search engines transfer ranking to the new URL and browsers cache the redirect.
Causes and fixes
Common causes
- A site redesign or domain change
- Redirecting HTTP to HTTPS
- Adding or removing a trailing slash or www
How to fix
- Make sure the move is really permanent: browsers cache 301s for a long time, so mistakes are hard to undo
- A POST may turn into a GET after the redirect; use 308 to keep the method
- Avoid redirect chains and loops; point straight at the final URL
Specification: RFC 9110 §15.4.2
The resource is temporarily at the URL in the Location header; keep using the original URL. Often used after sign-in; search engines keep the original URL.
Causes and fixes
Common causes
- Redirects after signing in, signing out or submitting a form
- Temporary redirects by language or device
- A/B tests or maintenance pages
How to fix
- Use 301 or 308 when the URL has changed for good
- Browsers usually follow a 302 after POST with GET; use 307 to keep the method
Specification: RFC 9110 §15.4.3
Fetch the result with GET from the URL in the Location header. Used after a form POST to show a result page (Post/Redirect/Get), so reloading does not resubmit.
Specification: RFC 9110 §15.4.4
The resource has not changed since the client’s cached copy (checked with If-None-Match or If-Modified-Since), so the cache can be used. The response has no body.
Causes and fixes
Common causes
- The browser revalidated its cache with an ETag or Last-Modified date; this is normal
How to fix
- If you see stale content, make sure the server changes the ETag when files change, or put a hash in static file names
- While developing, tick “Disable cache” in the developer tools
Specification: RFC 9110 §15.4.5
Told the client to go through a given proxy. Deprecated for security reasons; browsers ignore it.
Specification: RFC 9110 §15.4.6
Was “Switch Proxy” in an early draft. No longer used, but the number stays reserved.
Specification: RFC 9110 §15.4.7
A temporary redirect like 302, but the client must repeat the same method and body (a POST stays a POST). Browsers also show 307 when HSTS upgrades a request to HTTPS internally.
Specification: RFC 9110 §15.4.8
A permanent redirect like 301, but the client must repeat the same method and body. Good for moving API endpoints.
Specification: RFC 9110 §15.4.9
4xx Client errors
The server cannot process the request because it is malformed, has invalid parameters or a body it cannot parse.
Causes and fixes
Common causes
- Invalid JSON, or a Content-Type that does not match the body
- Missing or badly formatted parameters
- Oversized or corrupted cookies or headers
- Unencoded special characters in the URL
How to fix
- Read the error details in the response body
- Validate the request body with a JSON formatter and check the Content-Type
- If a web page shows 400, clear that site’s cookies and try again
Specification: RFC 9110 §15.5.1
Authentication is required and was missing or invalid. Despite the name, it means “unauthenticated” (the server does not know who you are). The response should include a WWW-Authenticate header.
Causes and fixes
Common causes
- Not signed in, or the session expired
- A missing, mistyped or expired API key or bearer token
- A malformed Authorization header (for example, missing “Bearer ”)
How to fix
- Sign in again or refresh the token
- Check the token’s expiry (exp) with a JWT decoder
- Make sure the Authorization header matches the API documentation
Specification: RFC 9110 §15.5.2
Reserved for future payment schemes, with no standard use yet. Some services use it for exhausted quotas or expired subscriptions.
Specification: RFC 9110 §15.5.3
The server understood the request but refuses it: you do not have permission. Unlike 401, signing in again usually does not help.
Causes and fixes
Common causes
- Your account lacks permission for the resource
- Wrong file or directory permissions, or a directory without an index file and listing disabled
- A firewall, WAF or CDN blocking your IP or region
- A missing or invalid CSRF token
How to fix
- Check the account’s role and permissions
- Check file permissions and ownership on the server
- Look at the WAF or CDN block logs
Specification: RFC 9110 §15.5.4
The server cannot find the requested resource. The URL may be wrong or the page deleted, or the server may hide that it exists (instead of 403).
Causes and fixes
Common causes
- A typo, wrong letter case or missing trailing slash in the URL
- The page was deleted or moved without a redirect
- A wrong API path or version
- A single-page app whose routes are not set to fall back to index.html on the server
How to fix
- Check the spelling of the URL, or find the page again from the home page
- Set up a 301 redirect when you move a page
- Return 410 for content that is gone for good
Specification: RFC 9110 §15.5.5
The resource exists but does not support this HTTP method (for example, POST to a read-only resource). The Allow header lists the methods that work.
Causes and fixes
Common causes
- Using the wrong method (GET, POST, PUT, DELETE)
- A form posting to a static file or the wrong path
- The server or framework has no route for this method
How to fix
- Check the Allow header and the API documentation
- Make sure the route handles this method
Specification: RFC 9110 §15.5.6
The server cannot produce content that matches the request’s Accept headers (format, language or encoding).
Specification: RFC 9110 §15.5.7
Like 401, but the proxy in between needs you to authenticate. Common on corporate networks.
Specification: RFC 9110 §15.5.8
The server waited too long for the complete request and closed the connection.
Causes and fixes
Common causes
- A slow or unstable network
- An interrupted upload of a large file
- A client that opened a connection but sent nothing
How to fix
- Retry later
- Check the connection, or split large uploads into parts
Specification: RFC 9110 §15.5.9
The request conflicts with the current state of the resource, such as an edit conflict between two users or creating something that already exists.
Specification: RFC 9110 §15.5.10
The resource used to exist but has been removed for good, with no forwarding address. Clearer than 404; search engines drop it from their index faster.
Specification: RFC 9110 §15.5.11
The server requires a Content-Length header on the request.
Specification: RFC 9110 §15.5.12
A conditional header such as If-Match or If-Unmodified-Since did not hold. Used to avoid overwriting someone else’s newer changes.
Specification: RFC 9110 §15.5.13
The request body is larger than the server allows, typically a file upload. Formerly called “Payload Too Large”.
Causes and fixes
Common causes
- The uploaded file is over the limit
- Nginx’s client_max_body_size defaults to just 1 MB
- PHP’s upload_max_filesize and post_max_size, or a framework’s body limit
How to fix
- Compress the file or image before uploading
- Raise the limit at every layer: web server, reverse proxy and framework
Specification: RFC 9110 §15.5.14
The URL is longer than the server will handle, usually from putting lots of data in query parameters or a redirect loop that keeps adding them.
Specification: RFC 9110 §15.5.15
The server does not support the format of the request body (its Content-Type or Content-Encoding).
Causes and fixes
Common causes
- Sending JSON without Content-Type: application/json
- Uploading a file type the server does not accept
How to fix
- Set the correct Content-Type header
- Check which formats the API accepts
Specification: RFC 9110 §15.5.16
The range asked for in the Range header is outside the file, for example when resuming a download of a file that has since shrunk.
Specification: RFC 9110 §15.5.17
The server cannot meet the Expect header (usually Expect: 100-continue).
Specification: RFC 9110 §15.5.18
An easter egg from RFC 2324, the 1998 April Fools’ “Hyper Text Coffee Pot Control Protocol”: a teapot asked to brew coffee returns it. Not a real HTTP status, yet widely implemented.
IANA lists it as “(Unused)” and keeps it reserved because so much software already uses it.
Specification: RFC 9110 §15.5.19
The request reached a server that cannot answer for this host, typically when an HTTP/2 connection is reused across domains sharing a certificate.
Specification: RFC 9110 §15.5.20
The request is well-formed but its content is semantically wrong, such as failed field validation (bad email, password too short). Many APIs use it for validation errors.
Causes and fixes
Common causes
- Field validation failed
- Values of the right type that make no sense (an end date before the start date)
How to fix
- Read the per-field errors in the response and fix the input
Specification: RFC 9110 §15.5.21
WebDAV: the resource is locked and cannot be changed right now.
Specification: RFC 4918 §11.3
WebDAV: the action failed because another action it depended on failed.
Specification: RFC 4918 §11.4
The server will not risk processing a request that might be replayed. Used with TLS 1.3 0-RTT early data: resend after the handshake completes.
Specification: RFC 8470 §5.2
The server requires a different protocol, named in the Upgrade header (for example, a newer TLS or HTTP version).
Specification: RFC 9110 §15.5.22
The server requires a conditional header such as If-Match, to prevent lost updates when two clients edit the same thing.
Specification: RFC 6585 §3
Too many requests in a given time; you hit a rate limit. The Retry-After header may say how long to wait.
Causes and fixes
Common causes
- A loop or retries that fire too often
- Going over the API plan’s quota
- Many users sharing one IP address or key
How to fix
- Wait for the Retry-After time, then retry
- Add exponential backoff (double the wait on each retry) and caching
- Batch requests or upgrade the plan
Specification: RFC 6585 §4
The request headers are too large to process, most often because too many cookies have piled up.
Causes and fixes
Common causes
- A site or its subdomains have set a lot of cookies
- A very long Referer or custom header
How to fix
- Clear that site’s cookies
- On the server, set fewer cookies or raise the header size limit
Specification: RFC 6585 §5
The resource is unavailable because of a legal demand, such as a government order, court ruling or copyright takedown. The number nods to the novel Fahrenheit 451.
Specification: RFC 7725 §3
5xx Server errors
The server hit an unexpected error and could not complete the request. It is a server-side problem, not something you did wrong.
Causes and fixes
Common causes
- An unhandled exception in the code
- A broken configuration file (such as invalid .htaccess syntax)
- A failing database or other dependency
- Wrong file permissions
How to fix
- Users: reload later and contact the site owner if it persists
- Developers: check the server error log for the exception and stack trace
Specification: RFC 9110 §15.6.1
The server does not support the functionality needed, such as an HTTP method it does not recognize.
Specification: RFC 9110 §15.6.2
A gateway or reverse proxy (such as Nginx or a CDN) got an invalid response from the upstream server, or could not reach it at all.
Causes and fixes
Common causes
- The app server crashed, is restarting or is not listening on the expected port
- The reverse proxy points to the wrong upstream address or port
- The upstream sent a malformed response or closed the connection midway
How to fix
- Make sure the upstream service is running
- Check the proxy and upstream error logs
- Users: try again later
Specification: RFC 9110 §15.6.3
The server cannot handle the request right now, usually because it is overloaded or down for maintenance. Retry-After may say when to come back.
Causes and fixes
Common causes
- A traffic spike (ticket sales, promotions)
- Planned maintenance
- Exhausted resources such as connections or memory
How to fix
- Try again later
- During maintenance, return 503 with Retry-After so search engines keep the site indexed
- Scale up, or add queues and caching
Specification: RFC 9110 §15.6.4
A gateway or reverse proxy did not get a response from the upstream server in time.
Causes and fixes
Common causes
- The upstream takes too long (slow queries, heavy work)
- Network trouble between the proxy and the upstream
- A proxy timeout that is too short
How to fix
- Find and speed up the slow requests
- Move long jobs to the background (respond with 202)
- Raise the proxy timeout where reasonable
Specification: RFC 9110 §15.6.5
The server does not support the major HTTP version used in the request.
Specification: RFC 9110 §15.6.6
A server misconfiguration in content negotiation: the chosen variant is itself set up to negotiate, creating a loop.
Specification: RFC 2295 §8.1
WebDAV: the server does not have enough storage to complete the request.
Specification: RFC 4918 §11.5
WebDAV: the server found an infinite loop while processing the request (for example, bindings that refer to each other).
Specification: RFC 5842 §7.2
The request needs further extensions to be fulfilled. Its HTTP Extension Framework (RFC 2774) is now historic.
IANA marks this code as obsoleted.
Specification: RFC 2774 §7
You need to sign in to the network first, typically the Wi-Fi login page (captive portal) at hotels, airports and cafés.
Specification: RFC 6585 §6
How to use
- Type a code (like 404), a class (like 5xx) or a keyword in English or Chinese (like “timeout” or 逾時) in the search box.
- Use “Category” to show only one class, such as client errors (4xx).
- Frequent errors have “Causes and fixes” you can expand; the specification link takes you to the RFC section that defines the code.
- Every code has its own address: add #404 to this page’s URL to share it with a colleague.
FAQ
What do the five classes of HTTP status codes mean?
The first digit is the class: 1xx informational (request received, continuing), 2xx success, 3xx redirection (go to another URL), 4xx client errors (the request itself is wrong, such as a bad URL or missing permission) and 5xx server errors (the request was fine, but the server failed to handle it).
What is the difference between 401 and 403?
401 means “we do not know who you are yet”: you are not signed in or your credentials are invalid, and signing in usually fixes it. 403 means “we know who you are, but you are not allowed”; signing in again will not help, you need permission.
Should I use 301, 302, 307 or 308?
Use 301 or 308 for permanent moves and 302 or 307 for temporary ones. 301 and 302 may let browsers turn a POST into a GET, while 307 and 308 guarantee the same method and body. For web pages 301 is typical; for APIs prefer 308.
Is 418 “I’m a teapot” a real status code?
It is an easter egg from RFC 2324, a 1998 April Fools’ document. It is not a real HTTP status code, but so much software implements it that IANA marks 418 as “(Unused)” and keeps it reserved so it will never be assigned to anything else.
Why are 499, 520 and similar codes missing?
This list covers codes registered with IANA. 499 (Nginx: client closed the connection), 520–527 (Cloudflare) and the like are specific to one product or service, are not part of the HTTP standard, and their meaning varies, so check that service’s documentation.
Where does this data come from?
The list follows the IANA HTTP Status Code Registry. Names and definitions follow RFC 9110 (HTTP Semantics) and each code’s original RFC, and every code links to the section that defines it.
Related tools
URL Parser
Break a URL into scheme, host, port, path, query parameters and fragment, with IDN support and an editor that rebuilds the URL.Browser Info
See your browser version, user agent, screen size, language, time zone and supported features, and copy it all for a bug report.JWT Decoder
Decode a JWT’s header and payload, explain standard claims like exp and iat, and see whether it has expired. Decodes only; never verifies or uploads.