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.

HTTP 300 quick reference →

Quick reference

Code300
NameMultiple Choices
Category3xx redirect codes
SpecificationRFC 9110 §15.4.1
IANA statusAssigned
CacheableYes — cacheable by default
Client actionPresent 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 Accept header 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 Location header when 301 or 302 would be correct. This typically works because browsers follow the Location header, but it is technically a misuse of the code.
  • Apache mod_negotiation with 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 sufficient Accept-Language or Accept context.

How to handle HTTP 300

If you receive a 300 as a client

  1. Check the response body for a list of available representations and their URIs.
  2. If a Location header is present, it indicates the server's preferred choice — follow it as you would a 302.
  3. Parse the Alternates or body-listed URIs and request the most appropriate representation based on your requirements.
  4. 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

  1. Consider whether automatic selection is possible. If one representation is clearly preferred, select it and return 200 with the appropriate Content-Type.
  2. If you want a default, include a Location header pointing to the preferred variant. Most browsers and HTTP clients will follow it.
  3. 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.
  4. 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

CodeMeaningWhen to useClient auto-follow
300Multiple ChoicesGenuinely multiple valid representations, client must chooseOnly if Location header present
301Moved PermanentlyContent permanently moved to a new URLYes, caches redirect
302Found (temporary)Temporarily serving from different URLYes, does not cache
200 + VaryOK (negotiated)Server selected the best variant automaticallyN/A — direct response

Related Guides

HTTP 301 Moved Permanently · HTTP 302 Found · HTTP 406 Not Acceptable

Comparisons

HTTP 300 vs 301 · HTTP 300 vs 302

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