300 Multiple Choices 3xx
The request has multiple possible responses, and the client should choose one.
What does 300 mean?
A 300 Multiple Choices response means the requested resource corresponds to multiple possible representations — perhaps available in different formats, languages, or versions — and the server is presenting these options for the client (or user) to choose from, rather than picking one automatically.
This is part of HTTP's content negotiation framework, related conceptually to 406 (Not Acceptable). While 406 means "I can't satisfy any of your stated preferences," 300 represents a different scenario: "there genuinely are multiple valid options here, and rather than guessing, here they are — pick one."
How a 300 behaves
- It can carry a body listing the available options, ideally as links the client (or a human using a browser) can choose between
- It can include a
Locationheader suggesting a default/preferred choice, which automated clients might follow if they don't want to parse the full list of options - It's rarely automated in modern usage — most servers handle content negotiation (language, format) automatically based on
Accept-*headers rather than presenting a literal "choose one" response to the client
Common scenarios
If you're building the API or website:
- You're extremely unlikely to need 300 in typical modern API or website design — automatic content negotiation (returning the best-matching format/language based on
Accept-*headers, defaulting sensibly if no match) is almost always preferable to making the client choose explicitly - 300 might theoretically apply to a resource genuinely available in fundamentally different forms where automatic selection isn't appropriate (e.g., a document available as both a summary and full version, where neither is clearly "the same resource in a different format")
If you're calling an API:
- Essentially never encountered in standard REST API usage — content negotiation is virtually always handled automatically
If you're a website visitor:
- Not applicable in normal browsing — automatic format/language selection (or simple separate URLs for different versions) is how this is virtually always handled in practice
300 vs 406
| 300 Multiple Choices | 406 Not Acceptable | |
|---|---|---|
| What it represents | Multiple valid options exist; here they are | No option matches what the client said it would accept |
| Typical handling | Rarely used — automatic negotiation preferred | Also rarely used — servers usually return a default rather than failing |
Real-world examples
300 is genuinely rare in production systems — the vast majority of "multiple format/language" scenarios are handled either through automatic content negotiation (server picks the best match based on Accept-* headers, defaulting sensibly) or through simply having separate, distinctly-linked URLs for each variant (e.g., /document/en vs /document/fr) rather than a single URL that returns "choose one."
SEO implications
If a URL returns 300 (extremely uncommon), search engines would likely have difficulty determining which "choice" represents the canonical content to index — this is part of why separate, distinct URLs for different language/format variants (with appropriate hreflang and canonical tags) are the standard, SEO-friendly approach rather than relying on 300.
FAQ
Is 300 commonly used?
No — it's one of the least-used status codes in practice. Modern content negotiation is handled automatically (returning the best match based on Accept-* headers) or through separate URLs for different variants, rather than a literal "here are your choices" response.
How is 300 different from a redirect (301/302)?
Redirects (3xx codes like 301/302) point to a single destination the client should follow. 300 presents multiple options without designating one as definitively "the" destination (though it can suggest a default via Location).
Why don't APIs use 300 for versioning (e.g., "choose v1 or v2")?
API versioning is almost universally handled through explicit URL paths (/v1/, /v2/) or headers (Accept-Version), giving clients direct, explicit control — rather than a "here are the versions, pick one" response that would require additional round-trips.
Does 300 relate to language-specific pages (hreflang)?
Conceptually, both address "multiple versions of similar content," but in practice, separate URLs per language with hreflang annotations (an SEO-specific mechanism) are the standard approach — not 300, which would conflate multiple distinct, individually-indexable pages into a single ambiguous response.
Will using 300 ever be the "right" choice for a modern API?
It's difficult to construct a compelling modern use case — between automatic content negotiation, explicit versioning schemes, and separate URLs for distinct variants, the scenarios 300 was designed for are almost always better served by these more specific, more widely-supported alternatives.
Fun fact
300 is one of the only status codes whose core idea — "let the client pick from multiple options" — never found a comfortable home in how the web actually evolved, largely because both human users (who'd rather just click a specific link) and automated clients (which need deterministic, single answers to function) are better served by either automatic selection or explicit, separately-addressable alternatives than by a generic "multiple choices" response.