HTTP Status Codes
All 64 codes in the official IANA registry, explained in plain English — with typical causes, SEO notes and a lookup for any code.
HTTP Status Codes
Showing all 64 registered codes.
1xx Informational
The request was received and the process is continuing. These are interim responses, sent before the final one.
100 Continue
The server has received the start of the request and has not rejected it, so the client can go ahead and send the body.
Typical cause / when to use: A client sends Expect: 100-continue before uploading a large body. The server can answer 100 to say “go ahead”, or reject the request early (for example with 401 or 413) before any data is wasted.
101 Switching Protocols
The server agrees to switch this connection to a different protocol named in the Upgrade header.
Typical cause / when to use: Most often seen when a browser opens a WebSocket connection (Upgrade: websocket) over HTTP/1.1.
102 Processing
An interim response saying the server is still working on a long request, so the client should not time out.
Typical cause / when to use: Defined for slow WebDAV operations in RFC 2518. RFC 4918, which replaced RFC 2518, dropped it; the registration remains, but it is rarely used.
103 Early Hints
An interim response carrying Link headers so the browser can start preconnecting or preloading while the server is still preparing the real response.
Typical cause / when to use: Send hints such as Link: </style.css>; rel=preload; as=style while a slow page is being generated. Defined in RFC 8297 (an Experimental RFC); browsers that support it act on the hints early.
104 Upload Resumption Supported Temporary registration
An interim response telling the client that the server supports resumable uploads, so an interrupted upload can be continued instead of restarted.
Typical cause / when to use: Part of the IETF work on resumable uploads. It is a temporary registration (registered 2024-11-13, extended 2025-09-15, expires 2026-11-13), so check the registry before relying on it.
2xx Successful
The request was successfully received, understood and accepted.
200 OK
The request succeeded. For a GET, the response body is the requested page or file; for a POST, it describes the result of the action.
Typical cause / when to use: The normal answer for a page, file or API call that worked.
SEO: Google can index a URL that returns 200, but indexing is not guaranteed. An error message or empty page served with 200 is reported as a “soft 404” in Search Console — return a real 404 or 410 for content that does not exist.
201 Created
The request worked and created one or more new resources. The main one is identified by the Location header (or by the request URL if there is none).
Typical cause / when to use: A POST that adds a record, or a PUT that creates a resource that did not exist. Put the new resource’s URL in Location.
202 Accepted
The request was accepted for processing, but the processing has not finished — and it might still fail.
Typical cause / when to use: Asynchronous jobs such as video encoding, bulk imports or queued emails. Point the client to a status URL where it can check progress.
203 Non-Authoritative Information
Success, but a transforming proxy has modified the content from the origin server’s 200 response.
Typical cause / when to use: Rare. Sent by proxies that alter what they relay (for example by recompressing images) so clients know it is not the original.
204 No Content
Success, and there is deliberately no body to send back.
Typical cause / when to use: A save, PUT or DELETE where the client does not need a reply; also common for CORS preflight responses and analytics beacons. A 204 cannot contain a body.
205 Reset Content
Success; the client should reset the form or view that sent the request to its original state.
Typical cause / when to use: Rare: clearing a data-entry form after each submission so the next entry can start straight away. The response must not have a body.
206 Partial Content
The server is sending only the part (byte range) of the file that the client asked for with a Range header.
Typical cause / when to use: Seeking in audio or video, resuming a broken download, and download managers fetching a file in pieces. Each part is described by a Content-Range header.
207 Multi-Status
WebDAV: the XML body holds separate status codes for several resources or operations.
Typical cause / when to use: WebDAV-based systems (network drives, CalDAV and CardDAV calendars and contacts) when one request touches many resources.
208 Already Reported
WebDAV: members of this collection were already listed earlier in the same response, so they are not repeated.
Typical cause / when to use: Used inside a 207 Multi-Status body when bindings make the same resource reachable by several paths.
226 IM Used
The server fulfilled a GET, and the response is the result of one or more “instance manipulations” — such as a delta — applied to the current version.
Typical cause / when to use: Delta encoding in HTTP (RFC 3229): sending only the changes from a version the client already has. Rarely deployed.
3xx Redirection
Further action is needed to complete the request — usually following a new URL in the Location header.
300 Multiple Choices
The resource has several representations (for example different languages or formats) and the user or client can choose one.
Typical cause / when to use: Rare in practice — servers usually pick a representation automatically. If there is a preferred choice, the server should put it in the Location header.
301 Moved Permanently
The resource has a new permanent URL, given in the Location header. Links and bookmarks should be updated.
Typical cause / when to use: Permanent moves: a new domain, HTTP to HTTPS, a new URL structure. For historical reasons browsers may turn a POST into a GET when following it; use 308 if the method must be kept.
SEO: Google treats a 301 as a strong signal that the redirect target should be the canonical URL, so the new URL normally replaces the old one in search results. Use it for permanent moves, redirect each old URL to its closest equivalent, and avoid long redirect chains.
302 Found
The resource is temporarily at a different URL. The client should keep using the original URL in future.
Typical cause / when to use: Temporary redirects: login walls, short-term campaigns, language or location routing. Like 301, browsers may change POST to GET; use 307 to keep the method.
SEO: Google treats a 302 as a weak signal that the target should be canonical, so the original URL usually stays in search results. Fine for a genuinely temporary move; if the move is permanent, use 301 or 308.
303 See Other
The result of the request can be found at another URL, which the client should fetch with GET.
Typical cause / when to use: The Post/Redirect/Get pattern: after a form POST, redirect with 303 to a confirmation page so refreshing does not resubmit the form.
304 Not Modified
The copy the client already has is still current, so the server sends no body — the client reuses its cached copy.
Typical cause / when to use: The answer to a conditional request (If-None-Match with an ETag, or If-Modified-Since). Saves bandwidth for browsers, CDNs and crawlers.
SEO: Google says a 304 tells its indexing pipeline that the content is the same as at the last crawl; otherwise it has no effect on indexing. Supporting conditional requests saves crawl bandwidth on large sites.
305 Use Proxy Deprecated
Deprecated. It originally told the client to repeat the request through a proxy named in the response.
Typical cause / when to use: Do not use. It was deprecated in RFC 7231 because of security concerns about configuring a proxy from inside a response.
306 (Unused) Unused — reserved
Reserved. The code was defined in an earlier version of the HTTP specification and is no longer used.
Typical cause / when to use: Do not use. It is sometimes listed as “Switch Proxy”, the name it had in an early draft.
307 Temporary Redirect
The resource is temporarily at another URL, and the client must repeat the request there with the same method and body.
Typical cause / when to use: Temporary redirects where a POST, PUT or DELETE must stay what it is. Browser developer tools also show a “307 Internal Redirect” when HSTS upgrades http:// to https:// — that one is generated by the browser and never reaches your server.
SEO: Google treats 307 the same as 302: a weak signal, so the original URL normally stays in search results.
308 Permanent Redirect
The resource has moved permanently, like 301, but the client must not change the request method or body.
Typical cause / when to use: Permanent moves of API endpoints where a POST must stay a POST; also a valid choice for ordinary page moves. Defined in RFC 7538 and now part of RFC 9110.
SEO: Google treats 308 the same as 301: a strong signal that the target is the canonical URL.
4xx Client Error
The request contains bad syntax or cannot be fulfilled. The client should change something before retrying.
400 Bad Request
The server cannot or will not process the request because of something it sees as a client error, such as malformed syntax.
Typical cause / when to use: Invalid JSON, missing or malformed parameters, corrupt cookies or headers. API responses should say exactly what was wrong.
401 Unauthorized
The request lacks valid authentication credentials. Despite the name, it means “not authenticated”, not “not allowed”.
Typical cause / when to use: Missing, expired or invalid login, token or API key. The response must include a WWW-Authenticate header. If the user is signed in but lacks permission, send 403 instead.
402 Payment Required Reserved for future use
Reserved for future use. HTTP gives it no standard meaning.
Typical cause / when to use: Some APIs and platforms use it informally for billing problems such as an unpaid subscription or exhausted quota, but its behavior is not standardized.
403 Forbidden
The server understood the request but refuses to fulfil it. Sending the same credentials again will not help.
Typical cause / when to use: Insufficient permissions, IP or country blocks, firewall and bot-protection rules, disabled directory listings, wrong file permissions on the server. A server may answer 404 instead to hide that the resource exists.
404 Not Found
The server did not find anything at this URL, or will not say whether something exists. It does not say whether the absence is temporary or permanent.
Typical cause / when to use: Mistyped or outdated links, deleted pages, wrong routes. Serve a helpful 404 page with navigation or search.
SEO: Google drops URLs that return 404 from its index and gradually crawls them less often. 404s for pages that never existed or were removed on purpose do not harm the rest of the site. Redirect only when there is a genuinely equivalent page — Google may treat mass redirects of old URLs to the home page as soft 404s.
405 Method Not Allowed
The resource exists but does not support this HTTP method. The response must list the supported methods in an Allow header.
Typical cause / when to use: A POST to a read-only URL, a DELETE on something that cannot be deleted, or a form posting to a static file.
406 Not Acceptable
The server cannot produce a response that matches the client’s Accept headers (format, language or encoding) and will not send a default.
Typical cause / when to use: Rare — most servers send a default representation instead. Seen with strict APIs when the Accept header asks for a format they do not offer.
407 Proxy Authentication Required
Like 401, but the client must first authenticate with a proxy. The proxy sends a Proxy-Authenticate header.
Typical cause / when to use: Corporate or school proxies that require a login before allowing access to the web.
408 Request Timeout
The server did not receive a complete request within the time it was prepared to wait.
Typical cause / when to use: Slow or stalled uploads and idle connections; servers often send it just before closing an unused connection. The client may repeat the request.
409 Conflict
The request conflicts with the current state of the resource, and the user may be able to resolve it and try again.
Typical cause / when to use: Edit conflicts (someone else changed the record first), creating something that already exists, version mismatches on PUT.
410 Gone
The resource has been intentionally removed and is not coming back, and there is no forwarding address.
Typical cause / when to use: Discontinued products, expired promotions, deleted accounts — when you know the removal is permanent. If you are not sure, RFC 9110 says to use 404.
SEO: Google’s documentation treats every 4xx code except 429 the same way, so 410 and 404 both remove the URL from the index. 410 simply states that the removal is deliberate and permanent.
411 Length Required
The server refuses the request because it has no Content-Length header.
Typical cause / when to use: Uploads sent without a declared size to a server that needs to know the length in advance.
412 Precondition Failed
A condition in the request headers, such as If-Match or If-Unmodified-Since, turned out to be false.
Typical cause / when to use: Safe updates: a PUT with If-Match: "etag" fails because the resource changed after the client read it, which prevents one user silently overwriting another’s changes.
413 Content Too Large
The request body is larger than the server is willing or able to process. Earlier specifications called it “Payload Too Large” and “Request Entity Too Large”.
Typical cause / when to use: File uploads over the server’s limit (nginx’s client_max_body_size defaults to 1 MB, for example). If the limit is temporary, the server should send Retry-After.
414 URI Too Long
The URL is longer than the server is willing to interpret.
Typical cause / when to use: Huge query strings — often a form that should use POST sending its data with GET, or a redirect loop that keeps adding to the URL.
415 Unsupported Media Type
The request body is in a format the server does not support for this resource.
Typical cause / when to use: Sending JSON without Content-Type: application/json, uploading a file type the endpoint does not accept, or an unsupported Content-Encoding.
416 Range Not Satisfiable
The byte range requested in the Range header cannot be served — for example, it starts beyond the end of the file.
Typical cause / when to use: Resuming a download of a file that has since changed or shrunk. The server should send Content-Range: bytes */length with the current size.
417 Expectation Failed
The server (or a proxy on the way) cannot meet the requirement in the request’s Expect header.
Typical cause / when to use: Almost always about Expect: 100-continue reaching a server or proxy that does not support it. Retrying without the header usually works.
418 (Unused) Unused — reserved
Reserved and unused. RFC 2324, a 1998 April Fools’ RFC about controlling coffee pots, defined “418 I’m a teapot”. It was deployed as a joke often enough that RFC 9110 marks the code as unused and reserves it, so it cannot currently be assigned to anything else.
Typical cause / when to use: Do not use it for real errors: it has no meaning in HTTP. Some frameworks and websites return it as an Easter egg.
421 Misdirected Request
The request reached a server that cannot give an authoritative response for that URL’s origin (scheme, host and port).
Typical cause / when to use: Connection reuse in HTTP/2 and HTTP/3: a browser reuses a connection for another hostname covered by the same certificate, but that server is not set up for it. The client may retry on a new connection.
422 Unprocessable Content
The request is well-formed and in a supported format, but its contents are invalid. It was called “Unprocessable Entity” in WebDAV (RFC 4918).
Typical cause / when to use: Validation errors in APIs: JSON that parses correctly but contains an invalid email address, a negative quantity or an impossible date. Many API frameworks use it for form and schema validation failures.
423 Locked
WebDAV: the resource is locked.
Typical cause / when to use: Trying to change a file that another WebDAV client has locked for editing.
424 Failed Dependency
WebDAV: the action failed because another action it depended on failed.
Typical cause / when to use: One step in a multi-part WebDAV operation (such as PROPPATCH) failed, so the rest was not applied.
425 Too Early
The server will not process a request sent as TLS early data (0-RTT) because it could be replayed by an attacker.
Typical cause / when to use: TLS 1.3 0-RTT connections: a server or CDN refuses a request that is not safe to replay; the client retries after the handshake completes.
426 Upgrade Required
The server will not handle the request with the current protocol, but might after the client upgrades to the protocol named in the Upgrade header.
Typical cause / when to use: An endpoint that only speaks WebSocket or a newer protocol version. The response must include an Upgrade header.
428 Precondition Required
The server requires the request to be conditional — for example to include If-Match.
Typical cause / when to use: APIs that insist on If-Match for updates, so clients cannot overwrite each other’s changes (the “lost update” problem).
429 Too Many Requests
The client has sent too many requests in a given amount of time (rate limiting).
Typical cause / when to use: API rate limits, login-attempt throttling, protection against scrapers. Include a Retry-After header so clients know when to try again.
SEO: Google treats 429 as a sign that the server is overloaded — like a server error. Its crawlers slow down, and URLs that keep returning 429 can eventually drop out of the index. Use it only for short-term crawl-rate relief, never to block crawling.
431 Request Header Fields Too Large
The request headers are too large — either one header or all of them together.
Typical cause / when to use: Oversized or too many cookies for the domain, very long tokens or referrer URLs. For visitors, clearing the site’s cookies often fixes it.
451 Unavailable For Legal Reasons
Access is denied because of a legal demand, such as a court order or government censorship.
Typical cause / when to use: Content blocked in a country or removed for legal reasons. RFC 7725 suggests explaining the demand and identifying who made it with a Link header (rel="blocked-by"). The number is a nod to Ray Bradbury’s novel Fahrenheit 451.
5xx Server Error
The server failed to fulfil an apparently valid request.
500 Internal Server Error
A generic error: something unexpected went wrong on the server.
Typical cause / when to use: Unhandled exceptions, bugs, broken configuration (such as a faulty .htaccess), failed database queries. The server’s error log shows the real cause.
SEO: 5xx errors make Google’s crawlers slow down. Pages already indexed are kept for a while, but URLs that keep returning server errors are eventually dropped. A robots.txt file that returns 5xx can pause crawling of the whole site.
501 Not Implemented
The server does not support the functionality needed — typically it does not recognize the request method at all.
Typical cause / when to use: An unknown or unsupported method on a server that supports it for no resource. Compare 405, where the method is known but not allowed on this URL.
502 Bad Gateway
A gateway or proxy received an invalid response from the server behind it.
Typical cause / when to use: The application server behind a reverse proxy, load balancer or CDN crashed, closed the connection or sent a malformed response.
503 Service Unavailable
The server is temporarily unable to handle the request because of overload or maintenance.
Typical cause / when to use: Planned maintenance, deployments, overloaded servers, or no healthy backend behind a load balancer. Send Retry-After when you know how long it will last.
SEO: The right code for planned downtime: Google slows down crawling and keeps indexed pages during a short outage. If the 503 lasts for days, URLs can start to drop out of the index. Never serve a maintenance page with 200.
504 Gateway Timeout
A gateway or proxy did not get a response from the server behind it in time.
Typical cause / when to use: Slow database queries, long-running scripts or an unreachable backend exceeding the proxy’s timeout.
505 HTTP Version Not Supported
The server does not support, or refuses to support, the major HTTP version used in the request.
Typical cause / when to use: Rare. The response should explain which protocol versions the server does support.
506 Variant Also Negotiates
A server configuration error in transparent content negotiation: the chosen variant is itself set up to negotiate, creating a loop.
Typical cause / when to use: Very rare. It belongs to the experimental content-negotiation scheme of RFC 2295.
507 Insufficient Storage
WebDAV: the server cannot store what it needs to complete the request.
Typical cause / when to use: Uploading to a WebDAV or cloud drive that is full or over quota.
508 Loop Detected
WebDAV: the server found an infinite loop while processing a request with Depth: infinity.
Typical cause / when to use: Cyclic bindings in a WebDAV collection. It is not a redirect loop. Some shared hosting platforms also misuse 508 to mean “resource limit reached”.
510 Not Extended (OBSOLETED) Obsoleted
Obsolete. In the experimental HTTP Extension Framework (RFC 2774) it meant that further extensions to the request were required.
Typical cause / when to use: Do not use. The IETF moved RFC 2774 to Historic status, and the registry marks 510 as obsoleted.
511 Network Authentication Required
The client needs to authenticate to gain network access — typically a captive portal.
Typical cause / when to use: Hotel, airport and café Wi-Fi sign-in pages that intercept traffic until you log in or accept the terms. It should come from the intercepting network, never from an origin server.
No registered status code matches. Try a number, a class such as 4xx, or a simpler word.
Registry data: IANA HTTP Status Code Registry, last updated September 15, 2025. Unassigned values: 105–199, 209–225, 227–299, 309–399, 419–420, 427, 430, 432–450, 452–499, 509 and 512–599.
How to use this list
Every code in the official registry is listed above, grouped by class. Type in the filter box to narrow the list: a number matches
codes that start with it (40 shows 400–409), 4xx shows a whole class, and words search the names and
explanations (try redirect, cache or WebDAV). If you type a three-digit code that is not
registered, the tool explains how a client will treat it. Each code has its own link — for example
/web/http-status-codes/#404 — so you can point a colleague straight at it.
How status codes are structured
A status code is a three-digit number from 100 to 599. Only the first digit carries a category; the last two have no special meaning. RFC 9110 requires clients to understand the class of every code, and to treat a code they do not recognize as the x00 code of its class:
class = first digit (1–5) unrecognized code → treat as class × 100
The words after the number — the reason phrase, such as “Not Found” — are only a recommendation. Servers may change or omit them, and HTTP/2 and HTTP/3 do not send them at all, so software should always act on the number.
Worked example: an unknown code
Suppose an API returns 471. Type it in the filter box and the tool reports that 471 is unassigned in the IANA registry. Its first digit is 4, so under RFC 9110 a client must handle it as 4 × 100 = 400 Bad Request: something about the request needs fixing. A value such as 999 is outside 100–599 altogether, so it is not a valid HTTP status code, and RFC 9110 says to treat the response as a server error.
Choosing the right redirect
| Code | Permanent? | Keeps POST as POST? | Google treats it as |
|---|---|---|---|
| 301 | Yes | Not guaranteed | Strong canonical signal |
| 308 | Yes | Yes | Same as 301 |
| 302 | No | Not guaranteed | Weak canonical signal |
| 307 | No | Yes | Same as 302 |
| 303 | No | No — always GET | Weak canonical signal |
For moving pages, use 301 or 308 and point each old URL at its closest new equivalent. Keep chains short: Google follows up to ten redirect hops before giving up, and every hop slows visitors down. Use 303 after a form submission so that refreshing the result page does not submit the form again.
Errors that matter most
- 404 vs 410: both mean “not here”; 410 adds “and never will be”. Neither is a penalty — every site has them.
- Soft 404s: a “page not found” message sent with 200 OK confuses crawlers and monitoring. Send the real code.
- 429 and 503: both tell well-behaved clients and crawlers to slow down. Add
Retry-After(seconds or a date) so they know when to return. - 500 vs 502/504: a 500 comes from your application; 502 and 504 come from a proxy or CDN in front of it, so check the upstream server’s logs.
Caching and status codes
RFC 9110 marks some responses as heuristically cacheable — labelled “cacheable by default” above: 200, 203, 204, 206, 300,
301, 308, 404, 405, 410, 414 and 501. A cache may reuse them for a while even without explicit caching headers, which is why a
mistaken 301 or 404 can linger in browsers after you fix it. Send Cache-Control headers when it matters.
For other developer references, see the ASCII table (HTTP headers are ASCII text) and HTML color codes.
Frequently asked questions
What is the difference between a 301 and a 302 redirect?
Should a deleted page return 404 or 410?
Either is correct. 410 Gone states that the removal is deliberate and permanent; 404 Not Found makes no promise either way. Google’s documentation treats all 4xx codes except 429 the same, so both remove the page from its index. If a close replacement page exists, a 301 to it is better than either.
What is the difference between 401 Unauthorized and 403 Forbidden?
Is 418 “I’m a teapot” a real HTTP status code?
Not in HTTP. It comes from RFC 2324, a 1998 April Fools’ joke about coffee pots. Because it was used as a joke so widely, RFC 9110 lists 418 as “(Unused)” and reserves it so it cannot currently be assigned to anything else. It has no defined meaning, so do not use it for real errors.
What status code should a site return during maintenance?
503 Service Unavailable, ideally with a Retry-After header saying when to come back. Serving a maintenance page with 200 OK risks search engines indexing the maintenance message in place of your content.
What is a soft 404?
A page that tells visitors the content does not exist (or is empty) but returns 200 OK. Google detects many of these and reports them as soft 404s in Search Console. Return a real 404 or 410 instead.
Sources
- RFC 9110: HTTP Semantics, Section 15 (Status Codes) — RFC Editor
- Hypertext Transfer Protocol (HTTP) Status Code Registry — IANA
- RFC 6585: Additional HTTP Status Codes — RFC Editor
- RFC 2324: Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) — RFC Editor
- How HTTP status codes, and network and DNS errors affect Google Search — Google Search Central
- Redirects and Google Search — Google Search Central