Accept-Charset
Before UTF-8 became the dominant encoding on the web, clients needed a way to declare supported character sets. The Accept-Charset request header indicated which character encodings the client was willing to accept.
Usage
The Accept-Charset header was part of
content negotiation, allowing
clients to list preferred character encodings such as
utf-8, iso-8859-1, or windows-1252. The server
selected the best match and encoded the response body
accordingly.
Deprecated
This header is deprecated. Modern HTTP clients and servers default to UTF-8, making charset negotiation unnecessary. Sending this header reveals encoding preferences without practical benefit and increases the fingerprinting surface. Browsers no longer send the header, and servers are advised to ignore the value when received.
UTF-8 handles the full Unicode range and has become the
dominant encoding across the web. The
Content-Type response header
communicates the chosen encoding through its charset
parameter, making a separate negotiation step redundant.
Directives
charset-name
A character encoding name registered with IANA, such as
utf-8 or iso-8859-1.
\*
A wildcard matching any encoding not already listed in the header.
;q= (quality value)
A weight between 0 and 1 expressing relative
preference, following the same syntax used by
Accept. The default weight is 1.0.
Example
A client advertising a preference for UTF-8 with a
fallback to ISO 8859-1. The quality value 0.7 signals
the fallback is less preferred.
Accept-Charset: utf-8, iso-8859-1;q=0.7
A broader request accepting UTF-8 at full priority and any other encoding at a lower priority.
Accept-Charset: utf-8, *;q=0.5