300 Multiple Choices
The request has multiple possible responses. The client should choose one to proceed.
Meaning & Description
In theory, the server provides a list of resource links (often in the response body formatted as HTML or JSON) allowing the user to select the appropriate option. For machine clients, a `Location` header might indicate the server's preferred choice.
Common Causes
- Ambiguous `Accept` headers from the client.
- Server is configured for manual content negotiation but lacks a default representation.
- Legacy systems providing directory listings or multiple translations.
How to fix a 300 error
- Inspect the response body for a list of available URLs or formats.
- Check the `Location` header to see if the server has suggested a default choice.
- Ensure your client sends specific `Accept`, `Accept-Language`, or `Accept-Encoding` headers to help the server choose.
- Update your client logic to parse the 300 response payload and programmatically follow one of the provided links.
Browser & SEO Behaviour
Browser Behavior
Browsers typically do not auto-redirect on 300. Instead, they render the HTML response body so the user can manually click a link.
SEO Impact
Search engines generally do not follow 300 redirects automatically. They may index the links found in the response body HTML. It is rarely beneficial for SEO.
CDN Behavior
CDNs generally do not cache 300 responses unless explicitly instructed via Cache-Control headers, as the payload depends on content negotiation.
Code Examples
HTTP/1.1 300 Multiple Choices
Date: Mon, 12 Sep 2026 12:00:00 GMT
Location: /api/v2/resource.json
Content-Type: text/html
<ul>
<li><a href="/api/v2/resource.json">JSON version</a></li>
<li><a href="/api/v2/resource.xml">XML version</a></li>
</ul>app.get('/report', (req, res) => {
res.status(300)
.set('Location', '/report.pdf')
.json({
message: 'Multiple formats available',
options: ['/report.pdf', '/report.csv']
});
});from fastapi import FastAPI, Response
app = FastAPI()
@app.get("/report")
def get_report(response: Response):
response.status_code = 300
response.headers["Location"] = "/report.pdf"
return {
"message": "Choose a format",
"options": ["/report.pdf", "/report.html"]
}func handler(w http.ResponseWriter, r *http.Request) {
w.Header().Set("Location", "/report.pdf")
w.WriteHeader(http.StatusMultipleChoices)
w.Write([]byte("Multiple choices available: /report.pdf, /report.csv"))
}[HttpGet("report")]
public IActionResult GetReport()
{
Response.Headers.Add("Location", "/report.pdf");
return StatusCode(300, new {
Choices = new[] { "/report.pdf", "/report.csv" }
});
}curl -i -H "Accept: text/plain" http://api.example.com/dataRaw HTTP Response Example
HTTP/1.1 300 Multiple Choices
Location: /report.pdf
Content-Type: application/json
{
"choices": [
{"format": "pdf", "url": "/report.pdf"},
{"format": "csv", "url": "/report.csv"}
]
}Real-world Examples
Frequently Asked Questions
Why is 300 Multiple Choices rarely used in modern APIs?
Because modern APIs handle content negotiation differently. Instead of asking the client to choose after a request, APIs rely on the Accept header. If an unsupported format is requested, a 406 Not Acceptable is returned instead.
Do browsers automatically follow a 300 redirect?
No. Unlike 301 or 302 redirects, browsers will not automatically navigate to the URL in the Location header for a 300 status. They will display the response body, expecting the user to click a link.
How is 300 different from 406 Not Acceptable?
300 means the server has multiple valid options and is offering them to the client. 406 means the client specifically requested a format (via Accept headers) that the server cannot provide.
Should I use 300 for versioned APIs?
It is generally not recommended. While you could technically return a 300 with links to v1 and v2, it breaks automated clients. It is better to require the version in the URL or header.
Can a 300 response contain a Location header?
Yes, the server can include a Location header to suggest a preferred choice, but clients are not strictly required to follow it automatically.
Did You Know?
The 300 status code is one of the oldest HTTP status codes, designed in an era when browsers were expected to show native UI dialogs for content selection.
Because there is no standardized machine-readable format for the "choices" payload, 300 is effectively dead in modern REST API design.
Developer Tips
- Avoid using 300 Multiple Choices in automated REST APIs, as HTTP clients (like Axios or Fetch) will not know how to handle the response body automatically.
- If you must use 300, always provide a well-structured JSON or HTML body containing the alternative URLs.
- Consider using a 406 Not Acceptable instead if the client failed to specify a valid Accept header.
Interview Questions
These are questions you might face in a backend or API design interview that touch on HTTP 300.
What is the primary difference in browser behavior between 300 Multiple Choices and 301 Moved Permanently?
A browser will automatically and transparently follow a 301 redirect using the Location header. For a 300 Multiple Choices, the browser does not auto-redirect; it renders the response body so the user can manually choose an option.
When might you encounter a 300 status code in the wild?
It is exceedingly rare, but you might see it on legacy Apache servers using manual content negotiation, where an ambiguous request for an extension-less file resolves to multiple files (like index.html and index.php).
How should an API design handle a resource available in JSON and XML?
Instead of returning 300 Multiple Choices, the API should examine the client's Accept header. If the client asks for application/json, return JSON with a 200 OK. If the header is missing, return a sensible default.
Common Interview Mistakes
- Assuming that 300 is a standard automated redirect that HTTP clients will automatically follow.
- Confusing 300 Multiple Choices with 406 Not Acceptable (offering choices vs rejecting a specific request).