Content negotiation helper
Paste a client Accept header, list what the server can return, and see which representation wins under RFC 9110 rules. Build headers from MIME presets in the second tab.
Mode
Accept negotiator
Server-offered MIME types
Add MIME types the origin can return. Negotiation picks the best match for the Accept header above.
MIME result
Selected representation
Matched— specificity , q=
406 Not Acceptable — no offered type matches the Accept header and there is no */* fallback with q > 0.
No offered type matches (or every match has q=0).
Parsed Accept ranges
| Type | q | Raw |
|---|---|---|
Ranked candidates
| Rank | Offered | Matched Accept | Specificity | q | Score |
|---|---|---|---|---|---|
RFC 9110: higher specificity wins (exact > type/* > */*), then higher q, then earlier position in Accept.
Accept-Language
Server-offered languages
Winner: — q=
Accept-Encoding
Server-offered encodings
Winner: — q=
Output type
MIME presets
Select one or more types. Order follows click order.Select one type for the response Content-Type line.
Generated line
Shareable URL keeps offered types, builder presets, and short Accept values. Long Accept strings stay local. Everything runs in the browser.
About this tool
Content negotiation lets a client tell the server which representations it prefers — usually via Accept — and the server picks the best available match before setting Content-Type.
APIs often offer application/json and text/html; browsers send long Accept lists with q weights. Wrong matching means returning HTML to an API client or triggering a 406 Not Acceptable when nothing matches.
For a broader header reference, see the HTTP headers explainer.