Accept-Charset request HTTP header advertises which character set the client is able to understand. Using content negotiation, the server then selects one of the proposals, uses it and informs the client of its choice within the
Content-Type response header. Browsers usually don't set this header as the default value for each content type is usually correct and transmitting it would allow easier fingerprinting.
If the server cannot serve any matching character set, it can theoretically send back a
406 (Not Acceptable) error code. But, for a better user experience, this is rarely done and the more common way is to ignore the
Accept-Charset header in this case.
In early versions of HTTP/1.1, a default charset (
ISO-8859-1) was defined. This is no more the case and now each content type may have its own default.
|Header type||Request header|
|Forbidden header name||yes|
Accept-Charset: <charset> // Multiple types, weighted with the quality value syntax: Accept-Charset: utf-8, iso-8859-1;q=0.5
- A character set like
- Any charset not mentioned elsewhere in the header;
'*'being used as a wildcard.
- Any value is placed in an order of preference expressed using a relative quality value called the weight.
Accept-Charset: iso-8859-1 Accept-Charset: utf-8, iso-8859-1;q=0.5 Accept-Charset: utf-8, iso-8859-1;q=0.5, *;q=0.1
|RFC 7231, section 5.3.3: Accept-Charset||Hypertext Transfer Protocol (HTTP/1.1): Semantics and Context|
The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out https://github.com/mdn/browser-compat-data and send us a pull request.
|Chrome Full support Yes||Edge Full support Yes||Firefox Full support Yes||IE Full support Yes||Opera Full support Yes||Safari Full support Yes||WebView Android Full support Yes||Chrome Android Full support Yes||Firefox Android Full support Yes||Opera Android Full support Yes||Safari iOS Full support Yes||Samsung Internet Android Full support Yes|
- Full support
- Full support