406 - Not Acceptable
HTTP 406 Not Acceptable means the server cannot produce a representation matching proactive negotiation headers.
Last reviewed: February 12, 2026|Source-backed guidance under our editorial policy
Start Here
Use the closest compare guide, playbook, or adjacent error page to narrow the decision faster before you start changing production systems.
This page is part of the Error Reference library. Learn more about the project or report a correction.
What Does Not Acceptable Mean?
The resource exists, but negotiation constraints prevent any acceptable representation from being selected for this request.
Common Causes
- -Client sends Accept header limited to application/xml while endpoint can produce only application/json variants.
- -Strict language negotiation receives unsupported locale chain and declines fallback to default language representation.
- -Intermediate proxy injects narrow Accept values that exclude available compressed and uncompressed response formats.
How to Fix Not Acceptable
- 1Inspect Accept, Accept-Language, and Accept-Encoding headers against endpoint representation support.
- 2Relax overly strict negotiation preferences and request a server-supported variant.
- 3Retest with explicit acceptable variants and verify returned representation metadata.
Step-by-Step Diagnosis for Not Acceptable
- 1Capture full negotiation headers and variant metadata returned around the 406 response.
- 2Compare client preference matrix with server-supported media/language/encoding variants.
- 3Inspect intermediary normalization rules that may rewrite or strip negotiation headers.
- 4Retest by relaxing one constraint at a time to isolate the incompatible preference dimension.
Variant Matrix and Preference Resolution
- -Build explicit variant compatibility matrix (example: client requests
application/xml+fr-CA+br, server only has JSON inen-US). - -Check q-value precedence behavior (example:
q=0eliminates all otherwise valid media types).
Header Normalization and Edge Behavior
- -Trace proxy/CDN header rewrites (example: edge strips
Accept-Language, origin fallback logic returns no acceptable variant). - -Validate negotiation behavior parity across environments (example: staging supports gzip variant, production disabled).
Implementation Examples
curl -i -X GET https://api.example.com/v1/content -H "Accept: application/xml" -H "Accept-Language: fr-CA" -H "Accept-Encoding: br"
# Response:
# HTTP/1.1 406 Not Acceptable
# {"error":"Not Acceptable","code":"406"}const response = await fetch('https://api.example.com/v1/content', {
method: 'GET',
headers: { 'Accept': 'application/xml', 'Accept-Language': 'fr-CA', 'Accept-Encoding': 'br' }
});
if (response.status === 406) {
console.error('Handle 406 Not Acceptable');
}import requests
response = requests.get(
'https://api.example.com/v1/content',
headers={
'Accept': 'application/xml',
'Accept-Language': 'fr-CA',
'Accept-Encoding': 'br'
}
)
if response.status_code == 406:
print('Handle 406 Not Acceptable')Seen in Production
Client hardcodes unsupported locale/media combination
Frequency: common
Example: Mobile app requires application/xml plus locale variant not produced by API and receives 406 on content endpoints.
Fix: Fallback to supported media/language combinations and keep client preference list ordered by known server capabilities.
CDN variant configuration drifts from origin capabilities
Frequency: rare
Example: Edge advertises compressed variant that origin no longer serves, causing negotiation failures and 406.
Fix: Synchronize variant catalogs between edge and origin and validate with deployment-time compatibility checks.
Debugging Tools
- -curl -v with Accept, Accept-Language, and Accept-Encoding
- -API contract docs for supported media types
- -Gateway request/response header tracing
- -CDN variant and cache diagnostics
How to Verify the Fix
- -Re-run the request and confirm 406 is replaced by a matching representation response.
- -Validate Content-Type, Content-Language, and Content-Encoding across all hops.
- -Confirm clients can parse returned variants without fallback failures.
How to Prevent Recurrence
- -Document supported representation variants per endpoint contract.
- -Add Accept/Accept-Language/Accept-Encoding test matrices in CI.
- -Monitor 406 rates by route and client to catch negotiation regressions early.
Pro Tip
- -distribute machine-readable variant catalogs so SDKs can pre-negotiate acceptable headers before first request.
Official References
Provider Context
This guidance is specific to HTTP services. Always validate implementation details against official provider documentation before deploying to production.