HTTP headers · Request
Accept
Accept lists the media types the client prefers for the response.
Key facts
| Type | Request |
|---|---|
| Syntax | <code>text/html, application/json;q=0.9</code> |
| Wildcards | <code>type/*</code> and <code>*/*</code> |
| Quality | <code>q</code> from 0 to 1 |
| Default | <code>*/*</code> when omitted |
| Caching | Responses should send <code>Vary: Accept</code> |
| Standard | RFC 9110 §12.5.1 |
Preferences, not commands
The header is a list of media ranges with optional quality values. Higher q means more preferred; q=0 means not acceptable. A server may ignore the list and return something else, but well-behaved content negotiation honours it.
Browsers usually send a long list that favours HTML. API clients often send application/json. If the header is absent, any type is acceptable, which is why clients that care should always send it.
Caching negotiated responses
If the response changes with Accept, it must include Vary: Accept; otherwise a shared cache may serve an HTML page to a client that asked for JSON. The same rule applies to Accept-Encoding and Accept-Language.
Quality values are advisory and parsing is notoriously inconsistent. For machine clients, asking for one explicit type and checking the response is more reliable than building elaborate preference lists.
Frequently asked questions
What does q=0 mean?
The client explicitly refuses that type. It is different from omission, which leaves the preference unspecified.
Does Accept guarantee the response type?
No. It expresses preference. The server decides, and the Content-Type header states what was actually returned.