HTTP 300 Multiple Choices
HTTP 300 Multiple Choices means the server has more than one representation of the requested resource and is offering the client a choice rather than automatically selecting one. It is the only 3xx response where the server does not redirect automatically — the decision is left to the client or user.
Quick reference
| Code | 300 |
|---|---|
| Name | Multiple Choices |
| Category | 3xx redirect codes |
| Specification | RFC 9110 §15.4.1 |
| IANA status | Assigned |
| Cacheable | Yes — cacheable by default |
| Client action | Present the list of choices to the user or programmatically select the preferred representation |
What it means
HTTP 300 Multiple Choices means the requested resource has multiple representations — different languages, file formats, quality levels, or encodings — and the server is presenting a list rather than making the selection itself. This stands in contrast to how content negotiation usually works: when you send an Accept header and the server finds a matching representation, it returns that representation with a 200. If the server cannot automatically select from multiple equally valid options, 300 is the correct response.
RFC 9110 permits the server to include a Location header with the preferred choice, which most user agents will follow automatically. If no Location header is present, the client is expected to parse the response body, which lists the available representations and their URIs, and make a selection.
In practice, HTTP 300 is extremely rare on the modern web. It was more relevant in the 1990s when content negotiation was done at the server level and clients had more variation in supported formats. Today, nearly all content negotiation happens at the application layer, and specific redirect codes (301, 302, 307) handle automatic routing.
Common causes
- Server has no preferred representation: Multiple equally valid variants exist (e.g.,
document.en.html,document.fr.html) and the server's negotiation algorithm cannot select one without client input. - Accept header mismatch with available formats: The client's
Acceptheader lists acceptable formats but the server has multiple representations that all match with equal quality. Without a tiebreaker, 300 is the correct signal. - Legacy application using 300 as a redirect: Older applications occasionally return 300 with a
Locationheader when 301 or 302 would be correct. This typically works because browsers follow theLocationheader, but it is technically a misuse of the code. - Apache
mod_negotiationwith no default: Apache's transparent content negotiation via type-map files can return 300 when no single best variant is determinable and the request lacks sufficientAccept-LanguageorAcceptcontext.
How to handle HTTP 300
If you receive a 300 as a client
- Check the response body for a list of available representations and their URIs.
- If a
Locationheader is present, it indicates the server's preferred choice — follow it as you would a 302. - Parse the
Alternatesor body-listed URIs and request the most appropriate representation based on your requirements. - If building an HTTP client library, treat 300 as requiring user or programmatic intervention rather than auto-following.
If you control the server returning 300
- Consider whether automatic selection is possible. If one representation is clearly preferred, select it and return 200 with the appropriate
Content-Type. - If you want a default, include a
Locationheader pointing to the preferred variant. Most browsers and HTTP clients will follow it. - For permanent content moves, use 301 instead of 300. For temporary moves, use 302 or 307. Only use 300 when genuinely offering the client a choice.
- Implement proper
Accept-header-based content negotiation in application code rather than relying on server-level negotiation features that may produce 300.
Example exchange
GET /document HTTP/1.1 Host: example.com Accept-Language: en, fr;q=0.9 HTTP/1.1 300 Multiple Choices Location: /document.en.html Content-Type: text/html <ul> <li><a href="/document.en.html">English</a></li> <li><a href="/document.fr.html">Français</a></li> </ul>
In this exchange, the server cannot automatically select between English and French documents, so it offers both. The Location header suggests English as the preferred choice.
300 vs 301 vs 302 — choosing the right redirect
| Code | Meaning | When to use | Client auto-follow |
|---|---|---|---|
| 300 | Multiple Choices | Genuinely multiple valid representations, client must choose | Only if Location header present |
| 301 | Moved Permanently | Content permanently moved to a new URL | Yes, caches redirect |
| 302 | Found (temporary) | Temporarily serving from different URL | Yes, does not cache |
200 + Vary | OK (negotiated) | Server selected the best variant automatically | N/A — direct response |
Related Guides
HTTP 301 Moved Permanently · HTTP 302 Found · HTTP 406 Not Acceptable
Comparisons
Standards reference
This definition is derived from the IANA HTTP Status Code Registry and RFC 9110. Human-readable operational guidance by ErrorLookup. · HTTP 300 status reference