What is a quality factor (q-value)?

A q-value is a number from 0 to 1 attached to a media type with a semicolon, like text/html;q=0.8. It expresses relative preference: 1 is most preferred, 0 means not acceptable at all. The server picks the acceptable representation with the highest combined preference.

How does the server break ties between media types?

Per RFC 9110, higher q-value wins first. When q-values are equal, the more specific media type wins (text/html beats text/* beats */*). If both q and specificity tie, servers typically fall back to the order in which types were listed.

Why would a q-value of 0 ever be useful?

q=0 explicitly marks a type as unacceptable. You can accept everything but exclude one format, for example application/json then */*;q=0.8, application/xml;q=0 to say 'anything except XML'. This is a precise way to opt out of a representation.

How does this relate to privacy and fingerprinting?

The Accept header is part of a browser's request fingerprint. A minimal, predictable Accept header (matching common browser defaults) reveals less than an unusual custom one. Privacy-conscious clients keep it simple so they blend in with the crowd.

Is the q-value formatting strict?

Yes. RFC 9110 allows at most three decimal places and a value between 0 and 1 inclusive. This tool clamps and rounds to three decimals, omits q for the default of 1, and orders types so the header is unambiguous and standards-compliant.

Content Negotiation & Accept Header Builder

HTTP content negotiation lets a client tell the server which representations it prefers using the Accept header, and the server returns the best match. Getting the quality factors and ordering right matters for APIs that serve JSON, XML, or multiple formats from one URL. This tool builds a valid header from sliders and explains exactly how a server will rank the options.

How it works

An Accept header is a comma-separated list of media ranges, each optionally tagged with a quality factor:

Accept: application/json, text/html;q=0.9, */*;q=0.8

When a server negotiates, it scores each representation it can produce against the client’s list using the rules in RFC 9110:

Match the media range. A type matches type/subtype, the subtype wildcard type/*, or the full wildcard */*.
Compare q-values. The match with the highest q-value wins. A q-value of 0 means the type is not acceptable.
Break ties by specificity. When two ranges match with equal q, the most specific one applies — an exact type/subtype beats type/*, which beats */*.
Break remaining ties by order. If q and specificity are equal, most servers honour the order the client listed.

The builder formats q-values to at most three decimals, drops ;q=1 (the default), and lists types in descending preference so the output is unambiguous. The parser runs the same ranking on a pasted header and shows the resulting order.

Example

Given the rows application/json at q=1, application/xml at q=0.5, and */* at q=0.1, the tool emits:

Accept: application/json, application/xml;q=0.5, */*;q=0.1

A server that can produce both JSON and XML returns JSON, because 1.0 beats 0.5. If it can only produce plain text, the */*;q=0.1 range still makes that acceptable as a last resort.

Tips and notes

Use q=0 to explicitly reject a format while still accepting others.
Keep the header close to common browser defaults if you care about request fingerprinting — unusual Accept headers stand out.
Parsing and building both happen locally in your browser; nothing is sent anywhere.