Accept-Charset request HTTP header advertises which character encodings the client understands. Using content negotiation, the server selects one of the encodings, uses it, and informs the client of its choice within the
Content-Type response header, usually in a
charset= parameter. Browsers usually don't send this header, as the default value for each resource is usually correct and transmitting it would allow fingerprinting.
If the server cannot serve any character encoding from this request header, it can theoretically send back a
406 Not Acceptable error code. But for a better user experience, this is rarely done and the
Accept-Charset header is ignored.
In early versions of HTTP/1.1, a default character encoding was defined: ISO-8859-1. This is no longer recommended, and now each content-type may have its own default.
UTF-8 is now well-supported and the overwhelmingly preferred character encoding. To guarantee better privacy through less configuration-based entropy, all browsers omit the
Accept-Charset header: Internet Explorer 8+, Safari 5+, Opera 11+, Firefox 10+ and Chrome 27+ no longer send it.
|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 encoding name, like
- Any charset not mentioned elsewhere in the header;
*is used as a wildcard.
- Any encoding 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|
BCD tables only load in the browser