406 - Not Acceptable
HTTP 406 Not Acceptable means the server cannot produce a representation matching proactive negotiation headers.
Last reviewed: February 12, 2026|Editorial standard: source-backed technical guidance
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')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.
Decision Support
Compare Guide
HTTP 400 vs 422: Bad Request vs Unprocessable Content
Fix API payload issues faster by using 400 for malformed syntax and 422 for semantic validation failures, so clients correct format before business rules.
Playbook
CORS Error Fix Playbook (Preflight / Origin / Credentials)
Use this playbook to separate browser-enforced cross-origin policy failures from server-side CORS header and route defects and apply strict origin and credential controls safely.
Playbook
Validation Failure Playbook (400 / 422 / INVALID_ARGUMENT)
Use this playbook to separate malformed-request failures from semantic validation failures, then fix request contracts without broad server-side bypasses.
Official References
Provider Context
This guidance is specific to HTTP services. Always validate implementation details against official provider documentation before deploying to production.