Accept-Charset
The HTTP 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
Takeaway
The Accept-Charset header once enabled character
encoding negotiation but is now deprecated. UTF-8 is
the standard encoding, and the
Content-Type charset parameter
communicates encoding choices directly.
