HTTP Status Codes List & Search
Look up any HTTP status code by number, name, or keyword. Each entry explains what the code means, what usually causes it, and what to do about it, and you can filter by class from 1xx to 5xx. The main reference is RFC 9110. To inspect the response headers themselves, try the HTTP Header Analyzer.
🔒 Runs in your browser · Your data is never sent to a server
Separate several words with spaces to show only codes that match all of them. You can also type "4xx" to pick a class.
- 1xx Informational
100 Continue
An interim response: the request headers were accepted and the client may go on to send the body.
- Common uses and causes
- Returned before a large upload when the client sent Expect: 100-continue and the server is willing to accept it.
- What to do
- HTTP clients normally handle this for you. Application code rarely needs to care.
Spec: RFC 9110 §15.2.1
- 1xx Informational
101 Switching Protocols
The server is switching to the protocol requested in the Upgrade header.
- Common uses and causes
- Sent when a WebSocket connection is established.
- What to do
- If a WebSocket will not connect, check that your reverse proxy forwards the Upgrade and Connection headers.
Spec: RFC 9110 §15.2.2
- 1xx Informational
102 Processing
An interim WebDAV response saying the request was received but is still being processed.
- Common uses and causes
- Used for slow WebDAV operations to keep the client from timing out.
- What to do
- Rarely seen in ordinary web APIs. Use 202 for asynchronous work instead.
Spec: RFC 2518
- 1xx Informational
103 Early Hints
An interim response that lets the browser start preloading resources (via Link headers) before the final response is ready.
- Common uses and causes
- Sent while the server is still building the page, so CSS and JavaScript can begin loading early.
- What to do
- Useful for faster rendering when your CDN or server supports it. Clients that do not understand it ignore it.
Spec: RFC 8297
- 2xx Success
200 OK
The request succeeded and the response carries the result.
- Common uses and causes
- The most common success: the content for a GET, or the outcome of a POST.
- What to do
- Use 204 when there is no body and 201 for newly created resources. Do not return 200 for errors.
Spec: RFC 9110 §15.3.1
- 2xx Success
201 Created
The request succeeded and a new resource was created.
- Common uses and causes
- Returned after a POST or PUT that creates a resource.
- What to do
- Return the new resource’s URL in the Location header.
Spec: RFC 9110 §15.3.2
- 2xx Success
202 Accepted
The request was accepted, but processing is not finished yet (asynchronous work).
- Common uses and causes
- Used when the work runs in the background, such as sending email or running a long batch job.
- What to do
- Return a job ID or a status URL in the body so the client can check progress.
Spec: RFC 9110 §15.3.3
- 2xx Success
203 Non-Authoritative Information
The request succeeded, but a transforming proxy modified the content from the origin’s 200 response.
- Common uses and causes
- A proxy changed the response on the way through.
- What to do
- Rarely seen. Treat it like a 200.
Spec: RFC 9110 §15.3.4
- 2xx Success
204 No Content
The request succeeded and there is no body to return.
- Common uses and causes
- Used for DELETE, for PUT or PATCH that return nothing, and for CORS preflight responses.
- What to do
- Send no body. It can also tell the client to stay on the current page.
Spec: RFC 9110 §15.3.5
- 2xx Success
205 Reset Content
The request succeeded and the client should reset the view, such as clearing a form.
- Common uses and causes
- In theory, used to clear a form after it is submitted.
- What to do
- Almost never used in practice, and browser support is limited.
Spec: RFC 9110 §15.3.6
- 2xx Success
206 Partial Content
Only the part of the resource requested with a Range header is being returned.
- Common uses and causes
- Video seeking and resumable or chunked downloads of large files.
- What to do
- Use Content-Range to describe the range, and Accept-Ranges: bytes to advertise support.
Spec: RFC 9110 §15.3.7
- 2xx Success
207 Multi-Status
Results for several resources are reported individually in an XML body.
- Common uses and causes
- WebDAV operations that touch several files at once.
- What to do
- Check the status of each resource inside the body separately.
Spec: RFC 4918
- 2xx Success
208 Already Reported
The members were already listed earlier in this response, so they are not repeated (WebDAV).
- Common uses and causes
- WebDAV bindings, to avoid enumerating the same collection twice.
- What to do
- You will not meet this in typical web development.
Spec: RFC 5842
- 2xx Success
226 IM Used
The response is the result of one or more instance manipulations, such as a delta against the current version.
- Common uses and causes
- Delta encoding in HTTP (RFC 3229).
- What to do
- Practically unused in production.
Spec: RFC 3229
- 3xx Redirection
300 Multiple Choices
There are several possible representations and the client must choose one.
- Common uses and causes
- A resource exists in multiple languages or formats.
- What to do
- Rarely used. Prefer content negotiation with the Accept headers when the server can choose.
Spec: RFC 9110 §15.4.1
- 3xx Redirection
301 Moved Permanently
The resource has permanently moved. Use the new URL in Location from now on.
- Common uses and causes
- Site migrations, http to https redirects, and URL normalization such as www or trailing slashes.
- What to do
- Search engines transfer ranking to the new URL. Some clients change POST to GET, so use 308 to keep the method. Browsers cache it hard, so a wrong 301 is difficult to undo.
Spec: RFC 9110 §15.4.2
- 3xx Redirection
302 Found
The resource is temporarily at a different URL.
- Common uses and causes
- Post-login redirects, maintenance pages, A/B tests, and other temporary moves.
- What to do
- Use it when the original URL should stay. 307 keeps the method, and 303 clearly means "fetch with GET".
Spec: RFC 9110 §15.4.3
- 3xx Redirection
303 See Other
The result is at another URL, which should be fetched with GET.
- Common uses and causes
- The Post/Redirect/Get pattern: redirecting to a result page after a form POST.
- What to do
- Prevents duplicate submissions when the page is reloaded. The redirect target is always requested with GET.
Spec: RFC 9110 §15.4.4
- 3xx Redirection
304 Not Modified
The resource has not changed since the last fetch, so the cached copy can be reused.
- Common uses and causes
- The client sent a conditional request with If-None-Match (ETag) or If-Modified-Since.
- What to do
- Send no body. Return correct ETag or Last-Modified values to save bandwidth. If updates do not show up, suspect caching.
Spec: RFC 9110 §15.4.5
- 3xx Redirection
305 Use Proxy
The resource was meant to be accessed through a given proxy.
- Common uses and causes
- A historical code that is now deprecated.
- What to do
- Browsers ignore it for security reasons. Do not use it.
Spec: RFC 9110 §15.4.6
- 3xx Redirection
307 Temporary Redirect
The resource is temporarily at another URL. The method and body are preserved.
- Common uses and causes
- HSTS-driven http to https redirects inside the browser, and temporary moves that must keep POST.
- What to do
- Unlike 302, a POST is resent as a POST. A "307 Internal Redirect" in dev tools is the browser applying HSTS locally.
Spec: RFC 9110 §15.4.8
- 3xx Redirection
308 Permanent Redirect
The resource has permanently moved, and the method and body are preserved.
- Common uses and causes
- Permanent moves where POST and other methods must stay the same.
- What to do
- The method-preserving version of 301. Handy when moving API endpoints.
Spec: RFC 9110 §15.4.9
- 4xx Client error
400 Bad Request
The server cannot process the request because its syntax or content is invalid.
- Common uses and causes
- Malformed JSON, missing required parameters, invalid headers, oversized cookies, or illegal characters in the URL.
- What to do
- Re-check the body and headers. An API should say which field was invalid.
Spec: RFC 9110 §15.5.1
- 4xx Client error
401 Unauthorized
The request lacks valid authentication. Despite the name, it means "unauthenticated".
- Common uses and causes
- A missing, expired, or wrong token or cookie, or Basic auth is required.
- What to do
- Describe the scheme in WWW-Authenticate. If the user is signed in but lacks permission, use 403 instead.
Spec: RFC 9110 §15.5.2
- 4xx Client error
402 Payment Required
Reserved for future use to signal that payment is required.
- Common uses and causes
- Not defined by the standard, but some APIs use it for billing or quota problems.
- What to do
- Check the API’s own documentation. Do not rely on a standard meaning.
Spec: RFC 9110 §15.5.3
- 4xx Client error
403 Forbidden
The server understood the request but refuses to authorize it.
- Common uses and causes
- Missing permissions, IP restrictions, a forbidden directory listing, or a block from a WAF or bot protection.
- What to do
- Signing in again will not help. Check permissions, file modes, and WAF logs. Some sites return 404 instead to hide that a resource exists.
Spec: RFC 9110 §15.5.4
- 4xx Client error
404 Not Found
The server cannot find the requested resource.
- Common uses and causes
- A wrong URL, a deleted or moved page, a case mismatch in a file name, or a missed deployment.
- What to do
- Check the URL and add a 301 if the page moved. Use 410 for permanently removed content. Avoid soft 404s, which show a "not found" page with 200.
Spec: RFC 9110 §15.5.5
- 4xx Client error
405 Method Not Allowed
The HTTP method used is not allowed for this URL.
- Common uses and causes
- Sending a POST to a GET-only endpoint, or a POST to a static file.
- What to do
- List the allowed methods in the Allow header. A CORS preflight (OPTIONS) that is not handled also produces this.
Spec: RFC 9110 §15.5.6
- 4xx Client error
406 Not Acceptable
The server cannot produce a response matching the Accept headers.
- Common uses and causes
- A client demands Accept: application/xml but the server can only return JSON.
- What to do
- Review the Accept headers. Security modules such as mod_security can also return this on false positives.
Spec: RFC 9110 §15.5.7
- 4xx Client error
407 Proxy Authentication Required
The client must authenticate with the proxy first.
- Common uses and causes
- A corporate or other proxy requires credentials.
- What to do
- Send credentials in Proxy-Authorization. It is the proxy equivalent of 401.
Spec: RFC 9110 §15.5.8
- 4xx Client error
408 Request Timeout
The server gave up waiting for the client to finish sending the request.
- Common uses and causes
- A slow or stalled connection, or a connection opened without sending anything.
- What to do
- Check the network and retry. Review timeout settings on the server and load balancer too.
Spec: RFC 9110 §15.5.9
- 4xx Client error
409 Conflict
The request conflicts with the current state of the resource.
- Common uses and causes
- Duplicate unique values, edit collisions from concurrent updates, or version mismatches.
- What to do
- Have the client fetch the latest state and retry.
Spec: RFC 9110 §15.5.10
- 4xx Client error
410 Gone
The resource has been deliberately and permanently removed.
- Common uses and causes
- Pages or API endpoints that were intentionally retired.
- What to do
- Signals an intentional removal more strongly than 404, and can lead search engines to drop the URL sooner.
Spec: RFC 9110 §15.5.11
- 4xx Client error
411 Length Required
The server requires a Content-Length header.
- Common uses and causes
- A request with a body was sent without Content-Length to a server that insists on it.
- What to do
- Resend with Content-Length set to the body size in bytes.
Spec: RFC 9110 §15.5.12
- 4xx Client error
412 Precondition Failed
A condition in the request headers, such as If-Match, was not satisfied.
- Common uses and causes
- Optimistic locking with ETags where another update changed the resource first.
- What to do
- Fetch the latest resource and its ETag, then retry.
Spec: RFC 9110 §15.5.13
- 4xx Client error
413 Content Too Large
The request body is larger than the server is willing to process.
- Common uses and causes
- Large file uploads. Often the nginx client_max_body_size or an application limit.
- What to do
- Raise the limit or send a smaller file.
Spec: RFC 9110 §15.5.14
- 4xx Client error
414 URI Too Long
The request URI is longer than the server will accept.
- Common uses and causes
- Too much data in a GET query string, or a redirect loop that keeps growing the URL.
- What to do
- Send large data in a POST body. Check for redirect loops.
Spec: RFC 9110 §15.5.15
- 4xx Client error
415 Unsupported Media Type
The server does not accept the format of the request body (Content-Type).
- Common uses and causes
- Sending form data to a JSON-only API, or leaving out Content-Type.
- What to do
- Set a Content-Type the API accepts, such as application/json.
Spec: RFC 9110 §15.5.16
- 4xx Client error
416 Range Not Satisfiable
The range in the Range header lies outside the size of the resource.
- Common uses and causes
- A resumed download asking for bytes beyond the real file size.
- What to do
- Read the real size from Content-Range: bytes */size and correct the range.
Spec: RFC 9110 §15.5.17
- 4xx Client error
417 Expectation Failed
The server cannot meet the requirement in the Expect header.
- Common uses and causes
- A server or proxy that does not support Expect: 100-continue.
- What to do
- Resend without the Expect header.
Spec: RFC 9110 §15.5.18
- 4xx Client error
418 I'm a teapot
A joke code from an April Fools’ RFC: a teapot refusing to brew coffee (RFC 2324).
- Common uses and causes
- Used by some services as a custom response, for example to turn away bots.
- What to do
- It has no standard production use. If you see it, check that service’s documentation.
Spec: RFC 2324
- 4xx Client error
421 Misdirected Request
The request was sent to a server that cannot produce a response for it.
- Common uses and causes
- HTTP/2 connection reuse across hostnames when certificates or SNI settings do not line up.
- What to do
- Retry on a new connection and check the certificate’s SAN entries.
Spec: RFC 9110 §15.5.20
- 4xx Client error
422 Unprocessable Content
The syntax is valid but the content cannot be processed semantically.
- Common uses and causes
- Valid JSON that fails validation, such as a badly formatted email. Many APIs use this for validation errors.
- What to do
- A common convention is 400 for syntax errors and 422 for validation errors.
Spec: RFC 9110 §15.5.21
- 4xx Client error
423 Locked
The target resource is locked (WebDAV).
- Common uses and causes
- Another user is editing it, or a lock is held.
- What to do
- Wait until the lock is released, or send the lock token.
Spec: RFC 4918
- 4xx Client error
424 Failed Dependency
The request failed because an earlier operation it depended on failed (WebDAV).
- Common uses and causes
- A batch of operations where a prerequisite step failed.
- What to do
- Resolve the original failing operation (shown in the body) first.
Spec: RFC 4918
- 4xx Client error
425 Too Early
The server is unwilling to process a request that might be replayed.
- Common uses and causes
- Requests sent as TLS 1.3 0-RTT early data, refused to avoid replay attacks.
- What to do
- The client retries after the handshake completes. This is normally automatic.
Spec: RFC 8470
- 4xx Client error
426 Upgrade Required
The server refuses the current protocol and requires switching to another.
- Common uses and causes
- A server that demands TLS or a newer protocol.
- What to do
- Reconnect using a protocol listed in the Upgrade header.
Spec: RFC 9110 §15.5.22
- 4xx Client error
428 Precondition Required
The request must be conditional (for example with If-Match).
- Common uses and causes
- APIs that require If-Match to prevent lost updates.
- What to do
- Send the ETag you received in If-Match.
Spec: RFC 6585
- 4xx Client error
429 Too Many Requests
Too many requests were sent in a given time (rate limiting).
- Common uses and causes
- API quota limits, scraping, or repeated login attempts.
- What to do
- Wait for the number of seconds in Retry-After before retrying. Exponential backoff is the usual approach.
Spec: RFC 6585
- 4xx Client error
431 Request Header Fields Too Large
The request headers, as a whole or one of them, are too large.
- Common uses and causes
- Cookies that grew too large, or very long Authorization or Referer headers.
- What to do
- Remove unneeded cookies or raise the server’s header size limit.
Spec: RFC 6585
- 4xx Client error
451 Unavailable For Legal Reasons
The resource is withheld because of a legal demand such as censorship or a court order.
- Common uses and causes
- Government or court orders, copyright claims, and regional regulations. The number references the novel Fahrenheit 451.
- What to do
- The spec lets a Link header point to the party that imposed the block.
Spec: RFC 7725
- 5xx Server error
500 Internal Server Error
An unexpected error occurred on the server while handling the request.
- Common uses and causes
- Application exceptions, configuration mistakes (such as .htaccess), database connection errors, and unhandled bugs.
- What to do
- Check the server error logs. Keep details out of the response and write them to the log.
Spec: RFC 9110 §15.6.1
- 5xx Server error
501 Not Implemented
The server does not support the method or functionality needed for the request.
- Common uses and causes
- An unknown HTTP method or an unimplemented feature.
- What to do
- Check whether the method is supported. Use 405 when the method is known but not allowed.
Spec: RFC 9110 §15.6.2
- 5xx Server error
502 Bad Gateway
A gateway or proxy received an invalid response from the upstream server.
- Common uses and causes
- The app behind a reverse proxy (nginx, CDN, load balancer) is down or returning something invalid.
- What to do
- Check that the app server is running, its port, and crash logs. It also appears briefly during deploys and restarts.
Spec: RFC 9110 §15.6.3
- 5xx Server error
503 Service Unavailable
The server is temporarily overloaded or down for maintenance.
- Common uses and causes
- Maintenance, traffic spikes, resource exhaustion, or a deploy in progress.
- What to do
- Send Retry-After to hint at recovery. It is also the right code for a maintenance page, as it limits SEO impact.
Spec: RFC 9110 §15.6.4
- 5xx Server error
504 Gateway Timeout
A gateway or proxy did not get a timely response from the upstream server.
- Common uses and causes
- Slow upstream work such as heavy queries, network trouble, or a short proxy timeout.
- What to do
- Speed up or make the work asynchronous (return 202), or review the proxy timeout.
Spec: RFC 9110 §15.6.5
- 5xx Server error
505 HTTP Version Not Supported
The server does not support the HTTP version used in the request.
- Common uses and causes
- Connecting with a protocol version that is too old or too new.
- What to do
- Connect with a version the server supports.
Spec: RFC 9110 §15.6.6
- 5xx Server error
506 Variant Also Negotiates
The content negotiation configuration is circular.
- Common uses and causes
- A misconfigured transparent content negotiation setup.
- What to do
- Review the server configuration. Hardly ever seen today.
Spec: RFC 2295
- 5xx Server error
507 Insufficient Storage
The server cannot store what is needed to complete the request (WebDAV).
- Common uses and causes
- Disk space or storage quota is exhausted.
- What to do
- Check free space and quotas.
Spec: RFC 4918
- 5xx Server error
508 Loop Detected
The server stopped processing because it detected an infinite loop (WebDAV).
- Common uses and causes
- Circular references between WebDAV resources.
- What to do
- Remove the circular reference.
Spec: RFC 5842
- 5xx Server error
510 Not Extended
The request needs further extensions (HTTP Extension Framework) to be fulfilled.
- Common uses and causes
- An experimental spec that is rarely used.
- What to do
- Not a concern in typical web development.
Spec: RFC 2774
- 5xx Server error
511 Network Authentication Required
The client must authenticate to gain network access.
- Common uses and causes
- A captive portal, such as café or hotel Wi-Fi, intercepting the request.
- What to do
- Open a browser and complete the portal’s login page.
Spec: RFC 6585
How to use
- Type a code (404), a name (Not Found), or a keyword (auth, redirect) in the search box.
- Use the class buttons such as 4xx to narrow down client or server errors.
- Read each card for the meaning, common causes, and what to do.
Notes
- Meanings follow RFC 9110 (HTTP Semantics). Extension codes such as WebDAV’s come from RFC 4918 and similar documents.
- Causes and fixes are general guidance. The real cause depends on your server setup, framework, and CDN, so check your server logs too.
- Vendor-specific codes (such as Cloudflare’s 52x or nginx’s 499) and rarely used IANA entries are not listed.
- 306 is a reserved, unused code and is not included.
Glossary
Redirect
Sending the client to another URL, using a 3xx status code with a Location header. Permanent (301, 308) and temporary (302, 303, 307) redirects differ in how clients and search engines treat them.
ETag
An identifier for a version of a resource. With If-None-Match, the server can answer 304 when nothing changed and save bandwidth.
Retry-After
A header telling the client how long to wait (seconds or a date) before retrying. Sent with 429 and 503.
Reverse proxy
A server between clients and your app that forwards requests, such as nginx, a CDN, or a load balancer. 502 and 504 come from this layer.
FAQ
How do I choose between 301, 302, 307, and 308?
Decide whether the move is permanent or temporary, and whether the method must be preserved. Permanent and GET is fine: 301. Permanent and the method must stay: 308. Temporary: 302, or 307 to preserve the method. Redirecting to a result page with GET after a POST: 303. For site migrations where ranking should move to the new URL, use 301 or 308.
What is the difference between 401 and 403?
401 means the request is not authenticated (not signed in, or the token is invalid), and authenticating again may work. 403 means the server knows who you are but you lack permission, so retrying with the same credentials will not help. The name Unauthorized is misleading: it really means "unauthenticated".
What is the difference between 502, 503, and 504?
502 means an upstream app returned an invalid response (often because it is down). 503 means the server is temporarily overloaded or in maintenance. 504 means the upstream did not respond in time. Check the app status and logs for 502, load and maintenance settings for 503, and processing time and proxy timeouts for 504.
Should a missing page return 404 or 410?
Use 404 when a page is simply not found or never existed. Use 410 when you deliberately removed it for good; search engines tend to drop such URLs sooner. If the content moved to another URL, use a 301 redirect rather than either.
I got a status code that is not in this list
Vendor-specific codes, such as Cloudflare’s 520-530 or nginx’s 499, are not included. Check that service’s own documentation. Details of even standard codes can also vary a little between frameworks.
Share this page