Accept: asking for a media type, with preferences
Accept lists the media types a client can handle, each with an optional quality value, so the server can choose which representation of the resource to send.
At a glance
- Direction
- Request only. The server answers with a Content-Type.
- Defined in
- RFC 9110
- When absent
- The client accepts anything, exactly as if it had sent Accept: */*.
- Quality values
- q=0 to q=1, up to three decimal places, defaulting to q=1
- Specificity
- text/html beats text/* beats */* when several entries match.
- No match
- 406 Not Acceptable, or send your default representation anyway
- Pair with
- Vary: Accept on any response whose body depends on this header
In detail
The value is a comma separated list of media ranges. Each entry may carry a q parameter between 0 and 1 expressing relative preference, and q=0 means explicitly unacceptable rather than merely unwanted. A browser navigating to a page sends a long list that puts HTML first and finishes with a low weighted wildcard, which is why an API that ignores the header still works in a browser address bar.
Selection is by specificity first and quality second. A full type such as application/json outranks a subtype wildcard such as application/*, which in turn outranks */*, regardless of the q values attached to the less specific entries. Servers that sort purely on q get this wrong and hand a browser JSON because the wildcard at the end of its list happened to match.
When nothing on the list can be produced, the specification allows either a 406 Not Acceptable or sending a default representation anyway. In practice returning your normal representation is friendlier for APIs, because a 406 is almost always caused by a client library sending a narrow Accept header by accident rather than by a genuine inability to parse the response.
If the response body really does depend on this header, the response has to carry Vary: Accept or shared caches will store one representation and serve it to clients that asked for the other. That is the failure that produces JSON in a browser tab, or a stray HTML error page inside an API client.
Examples
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8Accept: application/json
HTTP/1.1 200 OK
Content-Type: application/json
Vary: AcceptAccept: application/json, text/plain;q=0Things that catch people out
- Accept describes what the response should be, not what the request body is. The type of an uploaded body goes in Content-Type.
- Sorting candidates by q value alone breaks browser navigations, because a browser's trailing */*;q=0.8 must not outrank a specific match earlier in the list.
- Returning 406 for an unrecognised Accept header makes an API brittle. Most clients that trip it are misconfigured rather than genuinely unable to read your default type.
Try it: HTTP Headers Checker
Check a live URL or paste headers you already have. It grades six security headers from A+ to F and lists every other header the response returned.
HTTP Headers Checker
LOCAL · Browser-OnlyView HTTP response headers for any URL
Enter any website URL to fetch and analyze its HTTP response headers. We'll automatically add https:// if needed.
Why Check Security Headers?
Security headers protect your website against common attacks like XSS, clickjacking, and MIME sniffing. They're set by your web server and cost nothing to implement. Missing security headers are one of the most common findings in security audits.
Related HTTP headers
All http headers →Content-Type: media type, charset and boundary
How Content-Type is structured, why the charset parameter still matters, what boundary does on a multipart upload, and how a wrong type breaks a page.
Accept-Language: language negotiation and its limits
How Accept-Language ranks languages, why matching should fall back from a region to a base tag, and why it is a poor way to pick a currency or a country.
Accept-Encoding: negotiating gzip, br and zstd
Which compression tokens clients send, how identity and the wildcard behave, why the response needs Vary, and how to test whether compression is really on.
Vary: which request headers change the response
How Vary extends a cache key, why Vary: User-Agent destroys hit rates, what Vary: * means, and the CORS case where forgetting Vary: Origin causes real bugs.
Content-Length: the size of the body in octets
What Content-Length counts, why it must never accompany Transfer-Encoding, what happens when it disagrees with the body, and when it may be omitted.
Content-Encoding: what compression was applied
What Content-Encoding declares, how it differs from Transfer-Encoding, why it changes the ETag, and how double compression happens in a proxy chain.
Tools for this
- HTTP Request Builder Free online HTTP request builder - build and test HTTP requests with custom headers and body
- HTTP Headers Checker Free online HTTP headers checker - view HTTP response headers for any URL