// test accept header priority against content-type options
Match Accept header values against available Content-Type options. Inspect priority, q-values, and negotiation outcome — free, browser-based.
Ready to negotiate
Enter an Accept header and available types, then click NegotiateEnter the raw Accept: value from an HTTP request, including any q-values.
Add the Content-Types your server can actually respond with, one per line.
See the best match, full priority ranking, and which rule (exact / wildcard / */*) triggered each match.
HTTP content negotiation is how a client and server agree on the format of a response. The client sends an Accept header listing acceptable MIME types with optional priority weights (q-values). The server picks the best available match.
A q-value (quality factor) is a decimal between 0 and 1 that indicates preference. q=1.0 is the highest (default if omitted). q=0 means "not acceptable." For example, text/html;q=0.9 is slightly preferred over */*;q=0.8.
The Accept header supports two wildcards: type/* (e.g., text/* matches any text subtype) and */* (matches any media type). Exact matches always win over wildcard matches, even if the wildcard has a higher q-value at the same level.
Specificity determines the winner when two rules have equal q-values. An exact match (text/html) has specificity 2, a type wildcard (text/*) has specificity 1, and the global wildcard (*/*) has specificity 0. Higher specificity wins ties.
Browsers list many MIME types to handle diverse server configurations. Modern browsers typically prefer text/html first, followed by XML variants, then images, then anything via */* at lower q-values — reflecting their rendering capabilities.
If no available Content-Type satisfies the Accept header (all have q=0 or no match exists), the negotiation fails. In HTTP, the server should respond with 406 Not Acceptable. This tool shows all available types as "Rejected" in that case.
This tool implements the core rules from RFC 7231 Section 5.3.2 — q-value parsing, exact vs wildcard precedence, and specificity-based tiebreaking. It covers the vast majority of real-world cases. Edge cases like parameter matching (e.g., charset=utf-8) are not yet included.
HTTP content negotiation is the mechanism defined in RFC 7231 that allows a client and server to agree on the most suitable representation of a resource. When a browser or API client makes a request, it sends an Accept header listing the media types (MIME types) it can handle, ranked by preference. The server inspects this list, compares it against the formats it can actually serve, and picks the best available match.
This process is fundamental to building flexible, interoperable web APIs. A single endpoint at /api/data might serve application/json for JavaScript clients, application/xml for legacy enterprise systems, and text/csv for data exports — all based purely on what the client requests in its Accept header.
💡 Looking for premium web development assets? MonsterONE offers unlimited downloads of templates, UI kits, and assets — worth checking out.
Each MIME type in an Accept header can carry an optional quality factor (q), a decimal from 0.001 to 1.000. When absent, q defaults to 1.0, meaning "fully preferred." A value of 0 means "not acceptable at all." This lets clients express nuanced preferences:
Accept: application/json, text/xml;q=0.9, */*;q=0.5 — JSON first, XML second, anything else at half priorityAccept: text/html;q=1.0, application/xhtml+xml;q=0.9 — classic browser preference orderingAccept: image/webp, image/png;q=0.8, image/*;q=0.6 — modern image format preferenceServers process these priorities in descending order, selecting the first available type that the client accepts. If multiple types share the same q-value, specificity rules break the tie.
The Accept header supports two wildcard forms. A type wildcard (text/*) matches any subtype under a given media type family. The global wildcard (*/*) matches anything. Specificity defines precedence when q-values are equal:
application/json matches only application/jsontext/* matches text/html, text/plain, text/csv, etc.*/* matches anythingThis means text/html;q=0.9 wins over text/*;q=0.9 which wins over */*;q=0.9, even though all three have identical q-values. The RFC mandates this to prevent overly broad rules from outcompeting precise declarations.
Web browsers typically send verbose Accept headers like text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8. This reflects the browser's full rendering capability hierarchy. Chrome and Firefox have slightly different orderings that can affect server behavior.
REST API clients often send Accept: application/json with nothing else, signaling they only want JSON. A well-behaved server should return 406 Not Acceptable if it can only serve XML.
cURL by default sends Accept: */* — it will take anything. This is why testing APIs with curl can mask content negotiation bugs that real clients would trigger.
Debugging content negotiation failures is notoriously tricky because the logic happens invisibly inside the HTTP stack. Frameworks like ASP.NET Core, Laravel, and Django all implement negotiation differently, with subtle variations in how they handle wildcards, parameter matching, and fallbacks. Common bugs include:
*/*;q=0.8 in a browser Accept header means the browser will accept JSON — leading to unexpected HTML responses in REST endpoints*/* and mask type-specific failuresq=0 is a hard rejection, not just low priorityThis tool lets you paste a real Accept header from browser DevTools or server logs, list what your endpoint can actually serve, and instantly see which type wins and why. The JSON export makes it easy to document negotiation behavior in API specs or test fixtures.
HTTP content negotiation is standardized in RFC 7231 (HTTP/1.1 Semantics), Section 5.3. The same rules apply in HTTP/2 and HTTP/3 since negotiation is a semantic-layer feature. Key points from the spec: media ranges are matched using a "most specific match" algorithm; parameters other than q are treated as media-type parameters and affect matching; and servers are not required to implement negotiation — they may ignore the Accept header and respond with any type, though well-designed APIs should always honor client preferences.