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.
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
