ErrorBase
Independent technical referenceOfficial site
  • Software and digital services
  • HTTP service

406

HTTP 406 Not Acceptable: no matching representation format

Verified with sources2 sourcesReviewed Oct 19, 2026
Technician coming? See the 2 steps they must show you

Risk level

Low

Usually safe to check without specialist tools.

Urgency

Medium

Quick answer

HTTP 406 Not Acceptable means the server has no representation matching your negotiation headers and refuses a default format. Check the outgoing Accept fields and inspect the 406 response body for available representations.

Safety first

Stop and check this first

  • Never assume that forcing the server to disregard Accept headers or sending Accept: */* guarantees the client can process the payload; RFC 9110 Section 12.4.1 warns that disregarding negotiation headers does not imply the client will be able to use the returned representation.

Safe checks you can perform

  • Inspect the 406 response payload and headers for available representations
  • Compare outgoing Accept headers against a permissive wildcard request
  • Test the same URL in a clean browser profile without custom header extensions

Leave these tasks to a qualified professional

  • Do not attempt this professional task: Configure origin server fallback representation or 406 alternatives list
  • Do not attempt this professional task: Update client Accept and quality-value headers to include supported formats

What a technician must be able to justify

Technician visit

These are the steps they must carry out and show you. Tick them as they work: if steps are skipped, do not accept a part swap.

These are not instructions for opening or handling the equipment yourself. They are the checks that should support a technical conclusion.

  1. Configure origin server fallback representation or 406 alternatives list

    What they doHave the API owner or web server administrator either configure the endpoint to return a default representation when proactive negotiation fails or generate a 406 payload listing the available representation characteristics and resource identifiers.

    They must show youa test request with an unsupported Accept header returning either the documented 406 representation list or the configured default representation with its Vary header.

    In writingthe server content-negotiation policy chosen for the route, the Vary header fields emitted, and the deployment commit reference.

  2. Update client Accept and quality-value headers to include supported formats

    What they doHave the client or API developer update the outgoing Accept, Accept-Language, or Accept-Encoding header fields (and any qvalue weights) to include a media range that the target resource actually produces, and verify that the client parser handles that format.

    They must show youthe side-by-side HTTP trace before and after updating the Accept header, showing a 2xx response and matching Content-Type header.

    In writingthe exact Accept header string configured in the client, the supported media types verified, and the parser check result.

Before accepting a part or repair

Nothing has been shown yet. Do not accept a part swap based on the code alone.

Follow these steps

Note: Follow the documented order. An error code identifies the affected system, but it does not prove by itself which part has failed.

  1. Inspect the 406 response payload and headers for available representations

    No special tools

    Who:
    Your web developer or API user inspects the failing HTTP response.
    How:
    Open the browser Network panel or API client log for the 406 exchange and read the response body, Content-Type, and any Vary header field.
    Result that matters:
    RFC 9110 Section 15.5.7 states that a 406 response should include content listing available representation characteristics and resource identifiers.
    If the response body lists supported media types or language identifiers, that confirms which representation characteristics the resource actually offers.
    If the 406 response body is empty or lists no alternatives, that indicates the server omitted representation discovery data and requires checking server route configuration.
    Evidence to keep:
    Save the full 406 response body, status line, Vary header value, and timestamp.

    Evidence: RFC 9110 section 15.5.7 - 406 Not Acceptable · RFC 9110 section 12.1 - Proactive Negotiation

  2. Compare outgoing Accept headers against a permissive wildcard request

    Tools required

    Who:
    Your developer runs a read-only GET or HEAD check with an HTTP client.
    How:
    Record the exact Accept, Accept-Language, and Accept-Encoding headers from the failing request, then send a single test request to the same URI with Accept: */*.
    Result that matters:
    In RFC 9110 Section 12.5.1, the media range */* groups all media types as acceptable, whereas omitting a wildcard rejects unlisted types.
    If the request with Accept:
    */* returns 200 OK and a Content-Type header, that confirms the original Accept header excluded the representation media type served by the resource.
    If the server still returns 406 when Accept is */*, that rules out media-type filtering and points to Accept-Language, Accept-Encoding, or a non-standard server rule.
    Evidence to keep:
    Keep both request header blocks and the resulting status code and Content-Type header from each test.

    Never disable authentication or content-type validation in production client parsers just to accept an unexpected response payload.

    Evidence: RFC 9110 section 12.5.1 - Accept · RFC 9110 section 15.5.7 - 406 Not Acceptable · RFC 9110 section 12.1 - Proactive Negotiation

  3. Test the same URL in a clean browser profile without custom header extensions

    No special tools

    Who:
    You or your QA tester can run this check without modifying server settings.
    How:
    Open the failing URL in a clean browser window with request-modifying extensions disabled and default language settings.
    Result that matters:
    Standard user agents send broad default media ranges and language fallbacks rather than single-type API headers.
    If the page loads normally in the clean browser profile, that isolates the 406 trigger to custom client headers, API SDK defaults, or browser extension overrides.
    If the 406 persists across independent clients, that confirms the origin server lacks an acceptable representation for general user agents on that route.
    Evidence to keep:
    Record the browser version, the exact URL tested, and a screenshot or HAR export of the network result.

    Evidence: RFC 9110 section 12.5.1 - Accept · RFC 9110 section 12.1 - Proactive Negotiation

Still not solved

If the error persists, stop here. See what the technician must do and show you.

Where this code applies

A code is meaningful only inside the right product and version context.

Primary scope

System
Software and digital services
Brand
HTTP
Product type
HTTP service

Known code variants

  • 406 Nicht akzeptabel
  • 406 No aceptable
  • 406 Non acceptable
  • 406 Non accettabile
  • 406 Not Acceptable
  • HTTP 406
  • HTTP status 406

What it means

In RFC 9110 Section 15.5.7 and the IANA HTTP Status Code Registry, 406 (Not Acceptable) indicates that the target resource lacks a current representation acceptable to the user agent according to proactive negotiation request headers (Accept, Accept-Language, Accept-Encoding, or Accept-Charset), and the server chooses not to serve a default representation. Because RFC 9110 Section 12.4.1 permits an origin server either to return 406 or to disregard the header field and serve a representation anyway, status 406 alone does not prove the HTTP server is broken; it reflects a mismatch between strict server selection rules and restrictive client media-range preferences.

Warnings and stop conditions

  • Lowsource verified

    Never assume that forcing the server to disregard Accept headers or sending Accept: */* guarantees the client can process the payload; RFC 9110 Section 12.4.1 warns that disregarding negotiation headers does not imply the client will be able to use the returned representation.

    Evidence: RFC 9110 section 12.5.1 - Accept · RFC 9110 section 12.1 - Proactive Negotiation

Symptoms and causes

Probable causes · in order

  • Restrictive Accept media range without a matching representationCommon

    The client sends an Accept header field restricted to specific media types or subtypes (or excludes others with q=0) that the target resource cannot generate.

    Evidence: RFC 9110 section 12.5.1 - Accept · RFC 9110 section 15.5.7 - 406 Not Acceptable · RFC 9110 section 12.1 - Proactive Negotiation

  • Unmatched Accept-Language or Accept-Encoding preferencesPossible

    Proactive negotiation also evaluates Accept-Language, Accept-Encoding, and Accept-Charset headers; if the client marks identity or fallback options with q=0, the server can reject the request with 406.

    Evidence: RFC 9110 section 12.5.1 - Accept · RFC 9110 section 12.1 - Proactive Negotiation

  • Origin server configured not to supply a default representationPossible

    RFC 9110 allows an origin server to disregard unsatisfied negotiation headers and return a default representation, so a 406 occurs when the server is explicitly configured to enforce strict negotiation or when a client sends Accept: */*;q=0.

    Evidence: RFC 9110 section 15.5.7 - 406 Not Acceptable · RFC 9110 section 12.1 - Proactive Negotiation

Virtual technician

Does 406 still appear after these checks?

Answer a few questions to narrow down the likely cause and the safest next action. Guidance only - it never replaces a professional.

Start diagnosis

Sources and technical references

  1. 1

    IANA HTTP Status Code Registry

    Internet Assigned Numbers Authority · 2025 · standard

  2. 2

    RFC 9110 - HTTP Semantics

    IETF / RFC Editor · 2022 · standard

Sources: IANA HTTP Status Code Registry · RFC 9110 - HTTP Semanticsreviewed 2026-10-19 · verified

Was this entry useful?