Identify the component returning 406, compare the accepted response formats with the endpoint contract, and verify a supported representation through a controlled request.
HTTP 406 means the responding component has not supplied a representation acceptable under the request’s negotiation conditions. It does not, by itself, mean that a page is missing, a login failed or a firewall must be disabled. Compare the exact request with the endpoint’s supported response formats before changing the website.
Explore this guide 7 sections
Accept: application/jsonNo acceptable response suppliedWhich representations are supported?Illustration only: the header is a possible client preference, not evidence of what caused your response.
Consider a fictional workshop directory whose public page opens normally, but an authorized reporting tool receives 406 when requesting the same resource. The two clients may ask for different representations. The useful diagnosis begins with their requests and the component returning the response, rather than the visible URL alone.
Identify the failing request precisely
Record the method, destination, response status and relevant negotiation headers in a safe test case. Separate a top-level page request from a background request made by the page. A browser window showing an error does not reveal which of those operations failed.
For the directory, use a fictional listing without private contact details. Keep credentials, cookies and unrelated headers out of shared evidence. Ask the authorized maintainer to preserve the narrow request characteristics needed to reproduce the issue in staging.
HTTP 415 after a form or API request: match the body to the endpoint explains an adjacent HTTP failure. Do not substitute its remedy simply because both cases involve a response code. A useful diagnosis follows the meaning and evidence of the specific request that failed.
Understand what the status establishes
MDN describes 406 Not Acceptable as a failure to provide an acceptable representation under proactive negotiation when a default is not supplied. Media type, language and encoding preferences can be relevant. The status alone does not identify the application’s intended behavior or the component that generated it.
In the fictional case, suppose the reporting tool asks exclusively for a format the directory does not provide. That is a hypothesis to verify against its contract. Another component could be generating the response, so do not conclude that the application rejected a format without checking its logs.
Read any safe response explanation and correlate it with authorized server evidence. A response branded by an intermediary is a useful clue, not a complete diagnosis. Avoid sharing a full production log when a small redacted event record answers the question.
If the failed response followed a write operation, establish whether that operation already took effect before repeating it. In the fictional directory, checking the listing’s state is safer than blindly resubmitting an upload to investigate how its acknowledgement was represented.
Separate accepted output from submitted input
Accept
In a request: which response media types the client can understand.
Content-Type
Which media type describes the message body. A request body and a response body are separate messages.
The Accept header describes media types a sender can understand, with preference weights available. It is a different question from the Content-Type describing a message body. Changing an upload’s body type is therefore not automatically a correction for unacceptable response output.
For the reporting tool, write its expectation in plain language: it needs structured listing data, whereas a human reader opens an HTML page. Confirm whether the documented endpoint supports that structured format. A URL that serves a human page is not necessarily a general-purpose data API.
Do not broaden the request to accept anything unless the client can actually handle what it receives. A nominally successful HTML response fed into a structured-data parser can replace the clear 406 with a confusing later failure.
Compare representation choices at the resource boundary
MDN’s content-negotiation guide distinguishes resources and their representations. Selection can depend on request information. That mechanism does not require every application route to offer multiple formats, nor does it promise that a server always rejects an unsupported preference with 406.
In staging, compare one known supported request with the failing one, changing a single relevant preference at a time. Keep the endpoint, authorization context and fixture data consistent. Record the resulting response format and whether the client can use it, rather than checking only the status number.
| Comparison | Question | Evidence to keep |
|---|---|---|
| Human page versus reporting tool | Do they request the same output? | Method, path and Accept |
| Requested versus documented format | Does this route support it? | Endpoint contract |
| Origin versus intermediary | Who produced the response? | Correlated redacted logs |
| Changed request succeeds | Can the client use that response? | Status, type and parsed result |
Choose the correction supported by the evidence
If the reporting tool requested an unsupported format, use a documented suitable endpoint or adjust the client to a supported representation it understands. If the server contract promises the requested output but does not deliver it, investigate that mismatch on the server side.
If an intermediary generated the response, ask its authorized maintainer to examine the specific event and relevant rule. Do not disable an entire protection layer as an exploratory shortcut. The response code is evidence to investigate, not permission to remove safeguards.
CORS errors on a website: trace the preflight and the actual response offers context for another layer of a web request. Keep transport, authentication and representation negotiation separate so a change does not accidentally repair one sample while breaking a different supported client.
Verify the complete consumer journey
- RequestMethod, path and headers.
- ContractSupported representations.
- ResponseStatus and media type.
- ConsumerCan it use the result?
Propose a small staging matrix covering the normal browser page, the documented reporting request and the previously failing preference. Include a genuinely unsupported format. Decide whether the intended product response is a useful error or a documented default that the consumer can handle.
Inspect the returned media type and expected data structure as well as the status. A 200 page containing an error message is not proof that a reporting operation succeeded. Check whether the fictional listing appears correctly in the receiving tool.
These are proposed checks, not tests performed on a reader’s hosting. HTTP 401 or 403 on a website: find the refusing layer before changing access addresses a related response-processing issue and may help once the evidence identifies that boundary, without turning it into a universal 406 fix.
Leave a reproducible explanation
The final record should identify the failing preference, supported representation, responsible component and verified consumer outcome. Include the minimal safe example needed to reproduce the behavior later.
The durable correction aligns what a client asks for with what the endpoint can appropriately provide. It does not depend on pretending every format is supported or accepting a response that the client cannot understand.
Sources and verification
Editorial review 2026-10-15. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- MDN: 406 Not AcceptableChecked 406 indicates no acceptable representation is supplied under proactive negotiation.
Limits: The status alone does not identify which component generated it. - MDN: Accept headerChecked Accept describes understood media types and supports relative preferences.
Limits: Accept is distinct from a message body Content-Type. - MDN: Content negotiationChecked A resource can have representations selected using request information.
Limits: Negotiation does not mean every endpoint supports every format.