The 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
<charset>
utf-8
or iso-8859-15.
*
'*'
being used as a wildcard.;q=
(q-factor weighting)Accept-Charset: iso-8859-1 Accept-Charset: utf-8, iso-8859-1;q=0.5 Accept-Language: utf-8, iso-8859-1;q=0.5, *;q=0.1
Specification | Title |
---|---|
RFC 7231, section 5.3.3: Accept-Charset | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Context |
Desktop | ||||||
---|---|---|---|---|---|---|
Chrome | Edge | Firefox | Internet Explorer | Opera | Safari | |
Basic support | Yes | Yes | Yes | Yes | Yes | Yes |
Mobile | |||||||
---|---|---|---|---|---|---|---|
Android webview | Chrome for Android | Edge Mobile | Firefox for Android | Opera for Android | iOS Safari | Samsung Internet | |
Basic support | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
Content-Type
TE
, Accept-Encoding
, Accept-Language
, Accept
© 2005–2018 Mozilla Developer Network and individual contributors.
Licensed under the Creative Commons Attribution-ShareAlike License v2.5 or later.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Charset