HTTP 406 Not Acceptable

Q: What causes a 406 error?

A 406 is caused by a mismatch between the content types a client declares it accepts (via Accept, Accept-Language, Accept-Encoding, or Accept-Charset headers) and the content types the server can produce for the requested resource. Common causes include overly restrictive Accept headers, API version mismatches, and server-side content negotiation configuration errors.

Q: How do I fix a 406 error?

First, inspect the request's Accept headers. Use curl -v to see exactly what headers are being sent. If you control the client, broaden the Accept header to include the content type the server produces (e.g., Accept: application/json, */*). If you control the server, ensure it can produce at least one of the content types the client lists.

Q: Is 406 the same as 415?

No. 406 Not Acceptable is about the response — the server cannot produce a format matching the client's Accept headers. 415 Unsupported Media Type is about the request — the server cannot process the format the client sent in the request body. They are mirror problems: 406 is the output side, 415 is the input side.

HTTP 406 Not Acceptable occurs during content negotiation — the HTTP mechanism by which clients tell servers what response formats they can handle. When the client's Accept headers list types the server cannot produce for the requested resource, the server returns 406 instead of a response body.

406 is less common than most 4xx errors and is often a symptom of overly strict Accept headers on the client side rather than a server-side bug.

Quick reference

Code	406
Name	Not Acceptable
Category	4xx Client Errors
Specification	RFC 9110 §15.5.7
IANA status	Assigned
Client behavior	Review and broaden Accept headers. The server may include a list of acceptable content types in the response body.
Caching	Not typically cached. The response depends on the specific Accept headers sent.
In-depth guide	HTTP 406 content negotiation guide →

What it means

Content negotiation is how HTTP allows a single URL to serve different representations of the same resource — JSON or XML for an API endpoint, English or French for a web page, compressed or uncompressed for a large asset. The client advertises what it can handle using Accept headers; the server selects the best match.

406 occurs when there is no intersection between what the client says it accepts and what the server can produce. RFC 9110 specifies that the server should include a list of available representations in the response body, but this is rarely implemented in practice.

Note that RFC 9110 permits servers to ignore the Accept header and serve a default representation rather than returning 406. A 406 means the server has chosen strict enforcement of content negotiation rather than falling back to a default.

The Accept headers involved

Four separate negotiation headers can trigger 406 if unsatisfied: Accept (content type, e.g., application/json), Accept-Language (language, e.g., en-US), Accept-Encoding (compression, e.g., gzip), and Accept-Charset (character set, now largely obsolete). Each can independently cause a 406 if the server cannot satisfy it.

Common causes

Overly restrictive Accept header

A client sends Accept: application/xml but the server only produces application/json for the endpoint. This is common in API integrations where the client is configured for one format and the server has been updated to another. Fix: either add the correct format to the Accept header or use Accept: */* to accept any response format.

API version or content-type mismatch

REST APIs that use content-type versioning (e.g., Accept: application/vnd.api+json; version=2) will return 406 if the version requested is not supported. Verify the API version in use and check the API documentation for currently supported Accept header values.

Accept-Language mismatch

A client sends Accept-Language: zh-CN exclusively and the server only has English-language responses. This is rare because most servers default to their primary language rather than returning 406, but a strict negotiation server will return 406 rather than serve a language the client did not request.

Server content negotiation misconfiguration

A server configured with Apache mod_negotiation or similar technology may be misconfigured to require specific Accept headers and return 406 for anything else. Check server content negotiation settings and ensure a wildcard fallback (*/*) is handled.

How to diagnose and fix a 406 error

Inspect the request headers. Use curl -v URL to see exactly what Accept headers are being sent. The -H "Accept: ..." flag lets you test with different values.
Check what the server can produce. Review the API or server documentation for supported response content types. Test with Accept: */* to confirm the server will respond if you remove the constraint.
Broaden the Accept header. If you control the client, change the Accept header to include the format the server produces. Using Accept: application/json, */*;q=0.9 prefers JSON but falls back to anything else.
Check server content negotiation configuration. If you control the server and it's returning 406 unexpectedly, verify that the content negotiation logic includes a sensible default fallback rather than strict enforcement.
Check for proxy or CDN transformation. Some proxies modify Accept headers. Verify the headers arriving at the origin server match what the client sends.

406 vs 415 vs 400 vs 200 with wrong content

Code	Direction	Problem	Fix
406	Response	Server cannot produce a format matching client's Accept headers	Adjust Accept headers or server output formats
415	Request	Server cannot process the Content-Type the client sent	Change Content-Type header on the request
400	Request	Malformed request syntax or invalid parameters	Fix the request format or parameters
200 wrong format	Response	Server ignores Accept header and returns default format	Nothing to fix — server chose permissive negotiation

FAQ

What does HTTP 406 mean?

HTTP 406 Not Acceptable means the server cannot generate a response that matches the acceptable content types, languages, or encodings specified in the request's Accept headers. The server understood the request but cannot produce a response in any format the client declared it will accept.

What causes a 406 error?

A mismatch between the client's Accept headers and the content types the server can produce. Common causes: overly restrictive Accept headers, API content-type version mismatches, and server content negotiation misconfiguration.

How do I fix a 406 error?

Inspect your request's Accept headers with curl -v. If you control the client, broaden the Accept header to include the format the server produces. If you control the server, ensure it has a sensible default fallback.

Is 406 the same as 415?

No. 406 is about the response format (server cannot produce what you'll accept). 415 is about the request body format (server cannot process what you sent). They are mirror problems on opposite sides of the HTTP transaction.

Related resources

On this site: HTTP 406 content negotiation guide · HTTP 415 Unsupported Media Type · HTTP 400 Bad Request · HTTP 407 Proxy Authentication Required · All 4xx client errors

Comparisons: 406 vs 415

Standards: RFC 9110 §15.5.7 · IANA Registry · MDN Web Docs: 406