HTTP status codes

All 63 registered codes in plain words, with the RFC that defines each. The ones you will actually meet are marked; the ones that wake people up have their own debugging guides.

Guides

1xx Informational

100
Continue RFC 9110 §15.2.1
The server has seen the request headers and the client may go ahead and send the body.
More
A client that sends Expect: 100-continue waits for this interim reply before uploading a large body, so the server can reject the request (for example with 401 or 413) without the client wasting bandwidth. curl adds Expect: 100-continue automatically for larger POST bodies, which is why you sometimes see it in verbose output. Clients should not wait forever for it; most send the body anyway after a short delay.
101
Switching Protocolscommon RFC 9110 §15.2.2
The server agrees to switch the connection to the protocol the client asked for in its Upgrade header.
More
You see this when a WebSocket handshake succeeds: the client sends Upgrade: websocket and the server answers 101, after which the TCP connection carries WebSocket frames instead of HTTP. If a WebSocket connection fails with a 200 or 400 instead, a proxy in the path is often stripping the Upgrade and Connection headers. In nginx you must forward them explicitly with proxy_set_header Upgrade $http_upgrade and proxy_set_header Connection "upgrade".
102
Processing RFC 2518 §10.1
An interim reply telling the client the server is still working on a long request.
More
Defined by the original WebDAV specification so that clients would not time out during slow operations such as a deep COPY. RFC 4918, which replaced RFC 2518, dropped it, but it remains in the IANA registry. Few clients or servers use it today; you are unlikely to need it.
103
Early Hints RFC 8297 §2
An interim reply carrying Link headers so the browser can start preloading resources before the final response is ready.
More
A server or CDN sends 103 with headers such as Link: </app.css>; rel=preload; as=style while the application is still rendering the page. The browser can fetch those assets in parallel and then receives the real response (usually 200) on the same request. Browsers act on 103 only over HTTP/2 and HTTP/3, and some older HTTP/1.1 clients mishandle multiple interim responses.

2xx Success

200
OKcommon RFC 9110 §15.3.1
The request succeeded and the response carries the result.
More
For GET the body is the requested resource; for POST it is usually a description or result of the action. A 200 says only that HTTP-level processing worked: APIs that return 200 with an {"error": ...} body hide failures from caches, monitoring and retry logic. Prefer a 4xx or 5xx when the request did not do what was asked.
201
Createdcommon RFC 9110 §15.3.2
The request succeeded and created a new resource.
More
Typically returned by a POST to a collection or a PUT to a new URL. The server should include a Location header pointing to the new resource; if it is missing, the client has to guess the URL or parse it from the body. Returning 200 instead is not wrong, but 201 lets clients tell a create apart from an update.
202
Acceptedcommon RFC 9110 §15.3.3
The server accepted the request for processing but has not finished it, and may never complete it.
More
Used for asynchronous work: queuing a video transcode, a bulk import, or a report. A good 202 response tells the client how to follow up, usually with a status URL in Location or in the body. It does not promise success; the job can still fail later, so clients must poll or wait for a callback.
203
Non-Authoritative Information RFC 9110 §15.3.4
The request succeeded, but a transforming proxy changed the content the origin sent.
More
Meant for intermediaries that modify a 200 response, for example by recompressing images, so the client knows the payload is not exactly what the origin produced. It is rarely seen in practice. A cache can store it like a 200.
204
No Contentcommon RFC 9110 §15.3.5
The request succeeded and there is deliberately no response body.
More
Common for DELETE, for PUT or PATCH that do not echo the resource, and for CORS preflight replies. A 204 response cannot carry a body; any bytes the server sends after the headers break the connection framing. Client code that unconditionally parses JSON (await res.json()) throws on a 204, so check the status first.
Guide →
205
Reset Content RFC 9110 §15.3.6
The request succeeded and the client should reset the form or view that sent it.
More
Intended for data-entry interfaces: after a submission the user agent clears the form so the next entry can start. Like 204, it has no body. Browsers do not implement the reset behavior, so it is almost never used.
206
Partial Contentcommon RFC 9110 §15.3.7
The server is returning only the byte range(s) the client asked for with a Range header.
More
This is how video seeking, resumable downloads and parallel download managers work. A single range comes with a Content-Range header; several ranges come as a multipart/byteranges body. If a range request unexpectedly returns 200 with the whole file, the server or a proxy in front of it does not support ranges for that resource (check for Accept-Ranges: bytes).
207
Multi-Status RFC 4918 §11.1
A WebDAV response whose XML body reports a separate status for each of several resources.
More
Returned by WebDAV methods such as PROPFIND or a DELETE on a collection, where some members may succeed and others fail. The overall 207 says nothing about success; the client must read each <status> element in the body. Some non-WebDAV APIs borrow 207 for batch endpoints with a JSON body, which is non-standard but harmless if documented.
208
Already Reported RFC 5842 §7.1
Inside a WebDAV 207 response, marks a resource that was already listed earlier, so it is not repeated.
More
Defined by the WebDAV binding extension, where the same resource can appear under several paths. It prevents infinite or duplicated output when a client walks a collection that contains bindings back to itself. It appears only inside a Multi-Status body, never as a top-level response status in normal use.
226
IM Used RFC 3229 §10.4.1
The server fulfilled a GET by sending a delta (instance manipulation) relative to a version the client already has.
More
Part of the HTTP delta encoding proposal: the client lists the manipulations it accepts in A-IM, and the server answers with 226 and an IM header describing what it applied. It was never widely deployed, and you are unlikely to meet it outside of experiments.

3xx Redirection

300
Multiple Choices RFC 9110 §15.4.1
The resource has several representations and the client should pick one.
More
In theory the server lists the alternatives and may suggest one in Location. There is no standard format for the list, so browsers do not offer a choice and most sites use content negotiation or a plain redirect instead. It is rare in practice.
301
Moved Permanentlycommon RFC 9110 §15.4.2
The resource has a new permanent URL, given in the Location header.
More
Used for domain moves, HTTP-to-HTTPS redirects and changed URL structures; search engines transfer ranking signals to the new URL. Browsers cache 301s aggressively, often with no expiry, so a mistaken 301 can stick in users' browsers long after you fix the server. For historical reasons clients may turn a POST into a GET when following it; use 308 if the method must be kept.
Guide →
302
Foundcommon RFC 9110 §15.4.3
The resource is temporarily at a different URL, given in the Location header; keep using the original URL.
More
Called "Moved Temporarily" in HTTP/1.0. The classic use is redirecting to a login page or after a form post, though 303 states that intent more precisely. Browsers change a POST to a GET when following a 302 even though early specs said not to; use 307 if you need the method and body preserved.
Guide →
303
See Othercommon RFC 9110 §15.4.4
Go fetch the result from another URL with GET.
More
The standard way to implement Post/Redirect/Get: after a form POST succeeds, the server answers 303 pointing at a results page, and the browser loads it with GET, so a reload does not resubmit the form. Unlike 302, the switch to GET is required, not just tolerated. It does not mean the original resource moved.
Guide →
304
Not Modifiedcommon RFC 9110 §15.4.5
The client's cached copy is still current, so the server sends no body.
More
The answer to a conditional request carrying If-None-Match (an ETag) or If-Modified-Since. The client reuses its stored body and updates the stored headers from the 304. It is not an error, and it is not a redirect despite being in the 3xx range.
Guide →
305
Use Proxy RFC 9110 §15.4.6
Deprecated: once told the client to repeat the request through a proxy named in Location.
More
RFC 7231 deprecated it because letting a server redirect a client into an arbitrary proxy is a security risk. Browsers ignore it. Do not send it.
306
(Unused) RFC 9110 §15.4.7
Reserved; it was used in an early draft and is no longer defined.
More
An early HTTP/1.1 draft defined 306 as "Switch Proxy". The code was dropped before publication but kept reserved so that it is never given a new meaning. Nothing should send it.
307
Temporary Redirectcommon RFC 9110 §15.4.8
The resource is temporarily at another URL; repeat the same request, same method and body, there.
More
It is a 302 with the method guaranteed: a POST stays a POST. Browsers also show an internal 307 when HSTS forces an http:// URL to https://; that redirect never left the browser, so you will not find it in server logs. Use it for temporary moves of API endpoints that accept non-GET methods.
Guide →
308
Permanent Redirectcommon RFC 9110 §15.4.9
The resource has a new permanent URL; repeat the same request, same method and body, there.
More
It is a 301 with the method guaranteed. First defined in RFC 7538 and now part of RFC 9110. Use it when permanently moving an endpoint that receives POST, PUT or DELETE. Very old clients that predate 308 may not follow it.
Guide →

4xx Client error

400
Bad Requestcommon RFC 9110 §15.5.1
The server will not process the request because something in it is malformed.
More
The catch-all client error: invalid JSON, a broken header, an illegal character in the URL, a missing required parameter. Because it is so broad, a useful 400 response explains what was wrong in the body. If a browser gets a 400 on every page of a site, an oversized or corrupt cookie is a frequent cause; clearing the site's cookies is a quick test.
Guide →
401
Unauthorizedcommon RFC 9110 §15.5.2
The request lacks valid authentication; the client needs to log in or send a valid credential.
More
Despite the name it is about authentication (who you are), not permission. The server must include a WWW-Authenticate header naming the scheme it accepts, such as Bearer or Basic. Common causes are a missing or expired token, a token sent to the wrong environment, or a proxy that strips the Authorization header.
Guide →
402
Payment Required RFC 9110 §15.5.3
Reserved for future use; some services use it to mean payment or a paid plan is needed.
More
The original authors expected digital payments to need their own status code, but no standard use was ever defined. Some APIs (Stripe for declined cards, various SaaS products for exhausted quotas) return it with their own meaning, so read the body.
403
Forbiddencommon RFC 9110 §15.5.4
The server understood who you are (or does not care) and refuses the request.
More
Logging in again will not help: the identity is known but lacks permission, or the resource is blocked for everyone. Typical causes include file permissions the web server cannot read, a missing index.html with directory listing disabled, IP or country blocks, WAF rules, and an S3 bucket policy that denies access. Servers may return 404 instead to avoid revealing that the resource exists.
Guide →
404
Not Foundcommon RFC 9110 §15.5.5
The server has nothing at this URL, or will not admit that it does.
More
The most common error on the web. It does not say whether the absence is temporary or permanent; use 410 if you know a resource is gone for good. When a route you just deployed returns 404, check the URL path prefix, trailing slashes, case sensitivity and whether the proxy forwards that path to the right backend.
Guide →
405
Method Not Allowedcommon RFC 9110 §15.5.6
The URL exists, but it does not accept this HTTP method.
More
For example a POST to an endpoint that only defines GET. The server must list the allowed methods in an Allow header. A frequent cause is a missing trailing slash: the framework redirects to the slashed URL, the client follows with GET, and the GET-only route behind it, or a static file server, answers 405.
Guide →
406
Not Acceptable RFC 9110 §15.5.7
The server cannot produce a response in any format the client said it accepts.
More
Triggered by content negotiation headers such as Accept or Accept-Language. In practice most servers ignore unsatisfiable Accept headers and send their default format instead. If you hit it from an API, check that Accept includes the type the API produces, for example application/json.
407
Proxy Authentication Required RFC 9110 §15.5.8
A proxy between you and the server requires you to authenticate with it first.
More
The proxy's equivalent of 401. It sends Proxy-Authenticate, and the client retries with Proxy-Authorization. You usually meet it on corporate networks where package managers or CLIs are not configured with proxy credentials (check HTTPS_PROXY and the tool's proxy settings).
408
Request Timeoutcommon RFC 9110 §15.5.9
The server gave up waiting for the client to finish sending the request.
More
Sent when a connection is opened but the full request does not arrive in time, often on slow uploads or idle keep-alive connections. The server should close the connection afterward. It is about the client being slow to send, not the server being slow to answer; a slow server produces 504 at a proxy instead.
409
Conflictcommon RFC 9110 §15.5.10
The request conflicts with the current state of the resource.
More
Typical cases: creating a record whose unique key already exists, updating a resource that someone else changed in the meantime, or a git-style push that is not a fast-forward. The body should explain the conflict so the client can resolve it and retry. Kubernetes returns 409 when you update an object with a stale resourceVersion.
Guide →
410
Gonecommon RFC 9110 §15.5.11
The resource used to exist here, has been removed on purpose, and will not come back.
More
Stronger than 404: it tells clients and search engines to drop the URL. Use it for deleted content or retired API versions. Responses are cacheable by default.
Guide →
411
Length Required RFC 9110 §15.5.12
The server requires a Content-Length header on this request.
More
Some servers refuse chunked or unspecified-length bodies, notably for uploads. It often shows up when a client sends POST with no body and no Content-Length: 0. Sending an explicit length fixes it.
412
Precondition Failed RFC 9110 §15.5.13
A condition in the request headers, such as If-Match, did not hold, so the server did nothing.
More
Used for optimistic concurrency: the client sends If-Match: "<etag>" with a PUT, and if someone else changed the resource since, the ETag no longer matches and the server returns 412 instead of overwriting their change. The client should refetch, merge and retry.
413
Content Too Largecommon RFC 9110 §15.5.14
The request body is larger than the server is willing to accept.
More
Earlier specs called it "Request Entity Too Large" (RFC 2616) and "Payload Too Large" (RFC 7231). nginx returns it when a body exceeds client_max_body_size, which defaults to 1 MB, so file uploads failing at about 1 MB usually point there. Remember to raise the limit at every layer: proxy, application server and framework.
414
URI Too Long RFC 9110 §15.5.15
The URL is longer than the server will handle.
More
Formerly "Request-URI Too Long". It usually means a client is stuffing large data into query parameters, or a redirect loop keeps appending to the URL. Move large inputs into a POST body.
415
Unsupported Media Typecommon RFC 9110 §15.5.16
The server does not accept the body's format, as declared by Content-Type or Content-Encoding.
More
The usual cause is a JSON body sent without Content-Type: application/json, or a form-encoded body sent to an endpoint that only parses JSON. Check the header the client actually sent, not the one you meant to send.
416
Range Not Satisfiable RFC 9110 §15.5.17
The byte range requested with Range does not overlap the resource.
More
Formerly "Requested Range Not Satisfiable". Common when resuming a download of a file that has since shrunk or been replaced, or when the client already has the whole file. The server should send Content-Range: bytes */<length> so the client knows the actual size.
417
Expectation Failed RFC 9110 §15.5.18
The server cannot meet the requirement in the request's Expect header.
More
In practice this concerns Expect: 100-continue, the only expectation defined. Some old proxies reject it; the fix is to resend the request without the Expect header (for curl, pass -H "Expect:").
418
(Unused) RFC 9110 §15.5.19
Reserved. Known as "I'm a teapot" from a 1998 April Fools' RFC; it has no standard meaning in HTTP.
More
RFC 2324 (Hyper Text Coffee Pot Control Protocol, April 1, 1998) defined 418 for a teapot asked to brew coffee. It was a joke, never part of HTTP. So many frameworks and sites implemented it anyway that RFC 9110 marks the code as reserved, so it cannot be assigned a real meaning that would clash with deployed jokes. Some sites return it to bots they want to brush off; do not use it for real errors.
Guide →
421
Misdirected Request RFC 9110 §15.5.20
The request reached a server that cannot produce responses for that host name.
More
Mostly seen with HTTP/2 connection reuse: a browser reuses one TLS connection for two hosts that share a certificate and IP, but the server is not configured for the second host. The client should retry on a new connection. Mismatched TLS settings between virtual hosts behind the same IP are a common trigger.
422
Unprocessable Contentcommon RFC 9110 §15.5.21
The request is well-formed, but its content fails validation or business rules.
More
Called "Unprocessable Entity" in WebDAV (RFC 4918), which introduced it; RFC 9110 adopted it under the new name. Frameworks such as Rails and FastAPI use it for validation errors: valid JSON with a missing field, a value out of range, or an email in the wrong format. The body should list which fields failed and why.
Guide →
423
Locked RFC 4918 §11.3
The resource is locked, so this WebDAV operation is refused.
More
Returned when a client tries to modify a resource another client has locked with WebDAV LOCK. The client must wait or supply the lock token. Some non-WebDAV APIs reuse it for locked accounts or records.
424
Failed Dependency RFC 4918 §11.4
This action failed because an action it depended on failed.
More
Used in WebDAV multi-status responses, for example when one property update in a PROPPATCH fails and so all the others are rolled back. Outside WebDAV it is uncommon.
425
Too Early RFC 8470 §5.2
The server will not process a request sent in TLS 1.3 early data, because it might be replayed.
More
TLS 1.3 0-RTT lets a client send a request before the handshake finishes, but an attacker can replay that data. A server or CDN that cannot be sure the request is safe to repeat answers 425, and the client retries after the handshake completes. Browsers handle the retry automatically.
426
Upgrade Required RFC 9110 §15.5.22
The server refuses the request over the current protocol and names the one to use in an Upgrade header.
More
For example, an endpoint that only accepts WebSocket connections may return 426 to a plain HTTP request. The response must include Upgrade listing the acceptable protocols.
428
Precondition Required RFC 6585 §3
The server requires this request to be conditional, for example to carry If-Match.
More
Used to force clients into optimistic concurrency so that two editors cannot silently overwrite each other. The client should fetch the resource, read its ETag, and resend the update with If-Match.
429
Too Many Requestscommon RFC 6585 §4
The client has sent too many requests in a given time and is being rate limited.
More
The server may say when to try again with Retry-After, in seconds or as a date. Clients should back off exponentially with jitter rather than retry immediately, which only extends the block. Many APIs also send non-standard X-RateLimit-* headers showing the limit and remaining budget.
Guide →
431
Request Header Fields Too Large RFC 6585 §5
The request headers, all together or one of them, are too big for the server.
More
Usually caused by cookies that have grown too large, or by very long tokens in Authorization. Node.js returns 431 when headers exceed its default limit of 16 KB. Clearing the site's cookies is the quickest test.
451
Unavailable For Legal Reasons RFC 7725 §3
Access is blocked because of a legal demand, such as a court order or government censorship.
More
The number is a nod to Ray Bradbury's Fahrenheit 451. The response should explain the restriction and may identify the entity that imposed it with a Link header using rel="blocked-by".

5xx Server error

500
Internal Server Errorcommon RFC 9110 §15.6.1
Something went wrong on the server, and it has no more specific code to report.
More
Almost always an unhandled exception or crash in application code; the detail is in the server's error log, not the response. Clients cannot fix it by changing the request, though retrying idempotent requests can help with transient faults. Do not return stack traces in a 500 body in production.
Guide →
501
Not Implementedcommon RFC 9110 §15.6.2
The server does not support the functionality needed for this request, typically the HTTP method.
More
Different from 405: 501 means the server does not recognize the method for any resource, while 405 means this resource does not allow it. Some APIs return 501 for features that are planned but not built yet.
502
Bad Gatewaycommon RFC 9110 §15.6.3
A proxy or gateway got an invalid response, or no response, from the server behind it.
More
The proxy (nginx, a load balancer, a CDN) is working; the upstream application is not answering properly. Usual causes: the app process is down or restarting, it listens on a different port or socket than the proxy expects, or it crashed mid-request. Check the proxy's error log for the reason, then the upstream's logs.
Guide →
503
Service Unavailablecommon RFC 9110 §15.6.4
The server is temporarily unable to handle the request, from overload or maintenance.
More
It signals a temporary condition, and the server may send Retry-After to say when to come back. Load balancers return it when no healthy backend is available, and nginx returns it by default when limit_req or limit_conn rejects a request. Search engines treat a short-lived 503 as downtime rather than a removed page.
Guide →
504
Gateway Timeoutcommon RFC 9110 §15.6.5
A proxy or gateway waited too long for the server behind it to respond.
More
The upstream accepted the connection or request but did not reply within the proxy's timeout, for example nginx's proxy_read_timeout (60 seconds by default). The upstream may still be working on the request and finish it after the client has given up, which matters for non-idempotent operations. Find the slow query or external call before raising timeouts.
Guide →
505
HTTP Version Not Supported RFC 9110 §15.6.6
The server does not support the HTTP major version used in the request.
More
Rare in practice. It can appear when a client sends a malformed request line that the server parses as an unknown version, or when a server that only speaks HTTP/1.x receives something else.
506
Variant Also Negotiates RFC 2295 §8.1
The server's content negotiation is misconfigured: the chosen variant itself tries to negotiate.
More
Defined by the experimental Transparent Content Negotiation spec. It indicates a circular configuration on the server, not a client problem. You are unlikely to see it.
507
Insufficient Storage RFC 4918 §11.5
The server cannot store what the request needs it to store.
More
Defined for WebDAV, where a PUT or COPY can fail because the disk or the user's quota is full. Some non-WebDAV services use it for full disks or quotas as well. The condition is assumed to be temporary.
508
Loop Detected RFC 5842 §7.2
The server stopped an operation because it found an infinite loop.
More
Defined by the WebDAV binding extension for a request with Depth: infinity that runs into a cycle of bindings. Some hosting control panels reuse it when an account hits a resource limit, which is non-standard.
510
Not Extended RFC 2774 §7
Obsolete: the server required an HTTP extension the request did not declare.
More
Came from the HTTP Extension Framework, an experimental RFC that was never adopted. The IANA registry now marks 510 as obsoleted because that RFC has been moved to Historic status. Do not use it.
511
Network Authentication Required RFC 6585 §6
You must sign in to the network itself before you can reach anything, as on hotel or airport Wi-Fi.
More
Meant for captive portals: the intercepting network device answers with 511 and a link to its login page instead of silently redirecting. That keeps apps from mistaking the portal page for the real server's response. Origin servers should never send it.

Unofficial codes you will still see

Not in the IANA registry; specific to one server or service.

444
No Response nginx
nginx closed the connection without sending any response.
More
This is a configuration choice, not an error: return 444; tells nginx to drop the connection silently. It is used to discard scanners, requests with unknown Host headers, and other unwanted traffic. The client sees an empty reply or a connection reset; the 444 exists only in nginx's access log.
497
HTTP Request Sent to HTTPS Port nginx
A plain HTTP request arrived on a port where nginx expects TLS.
More
Seen when someone types http://example.com:443/ or a client is pointed at the TLS port without TLS. nginx returns a 400 page to the client and logs 497. You can catch it with error_page 497 https://$host$request_uri; to redirect such clients to HTTPS.
499
Client Closed Request nginx
The client disconnected before nginx could send the response.
More
nginx records 499 in its access log; the client never receives it because it is already gone. It usually means the upstream was slow and the user, a browser navigation, or a client-side timeout gave up first. A rise in 499s is a latency signal: look at upstream response times.
Guide →
520
Web Server Returned an Unknown Error Cloudflare
Cloudflare got an empty, malformed or unexpected response from the origin server.
More
Cloudflare's catch-all when the origin's reply makes no sense to it. Typical causes: the origin crashed or reset the connection mid-response, sent an empty reply, or sent headers too large for Cloudflare to accept (often from huge cookies). Check the origin's logs for the matching request.
521
Web Server Is Down Cloudflare
The origin server refused Cloudflare's connection.
More
Cloudflare reached the origin's IP, but the connection was refused: the web server is not running, or a firewall on the origin is blocking Cloudflare's IP ranges. Confirm the server is listening on ports 80/443 and that Cloudflare's published IP ranges are allowed.
522
Connection Timed Out Cloudflare
Cloudflare could not complete a TCP connection to the origin in time.
More
Packets to the origin were dropped rather than refused, so Cloudflare timed out waiting. Common causes: a firewall silently dropping Cloudflare's IPs, an overloaded server, or a wrong origin IP in DNS. Compare with 521 (connection refused) and 524 (connected, but the response was too slow).
523
Origin Is Unreachable Cloudflare
Cloudflare could not find a route to the origin server.
More
Usually the origin IP in the DNS record is wrong or no longer exists, or there is a routing problem between Cloudflare and the origin network. Check the A/AAAA records in the Cloudflare dashboard.
524
A Timeout Occurred Cloudflare
Cloudflare connected to the origin, but the origin did not send an HTTP response before Cloudflare's timeout.
More
The default timeout is 100 seconds on most plans. The origin is usually still working on a long request, such as a report or export. Make the work asynchronous (return 202 and let the client poll) or move it to a hostname that bypasses the proxy.
525
SSL Handshake Failed Cloudflare
The TLS handshake between Cloudflare and the origin failed.
More
Occurs with Full or Full (strict) SSL mode when the origin does not serve TLS on port 443, has no certificate for the hostname, or supports no cipher or TLS version Cloudflare offers. Test the origin directly with openssl s_client -connect <origin-ip>:443 -servername <host>.
526
Invalid SSL Certificate Cloudflare
In Full (strict) mode, Cloudflare could not validate the origin's certificate.
More
The certificate is expired, self-signed, issued for a different hostname, or missing intermediate certificates. Install a valid certificate (a Cloudflare Origin CA certificate also works in strict mode) rather than downgrading the SSL mode.