About AcceptEncoding.com

Last reviewed on 2026-04-28

What this site is

AcceptEncoding.com is a focused reference site about a single, narrow topic: the HTTP Accept-Encoding request header and the content-encoding algorithms it negotiates — gzip, Brotli, deflate, and Zstandard. The header is small, but everything it touches — page weight, time-to-first-byte, mobile data costs, CDN behaviour, cache keys — is large. The site exists to explain that surface area in plain language, with examples that you can copy into a real config file and verify with curl -H "Accept-Encoding: br" -I.

Who it's for

The reader we have in mind is a working developer, sysadmin, or site reliability engineer who needs an answer now: which compression should my Nginx server enable, and what changes if I add Brotli? Why is my CDN stripping the Content-Encoding header? What does q=0 in Accept-Encoding actually mean? Pages are written so you can land on one from a search result, get the specific answer, and leave. Cross-links lead deeper for readers who want the full picture.

Editorial approach

Every page here is built around the same principles:

  • Specification first. Behaviour described on this site is grounded in the relevant RFCs (notably RFC 9110 for HTTP semantics, RFC 1952 for gzip, RFC 7932 for Brotli, RFC 8478 for Zstandard) and the documentation of the servers and browsers themselves.
  • Practical second. Where vendor behaviour diverges from the spec — for example, how a CDN handles Vary: Accept-Encoding, or how a server picks between br and gzip when both are advertised — the page documents what the implementation actually does.
  • Worked examples. Configuration snippets are the compact form most engineers paste into a real server. They are written to be self-contained and verifiable from the command line.
  • No invented benchmarks. Numbers cited as "typical" are described as ranges drawn from public references rather than headline figures from a private test rig.

How content is produced

Articles are written and reviewed by contributors with hands-on experience deploying compression on production web servers and CDNs. Each guide is checked against current vendor documentation and tested against a recent build of the server it covers. Pages carry a "Last reviewed on" date so readers can tell at a glance when the material was last verified. When a relevant standard or default changes — for example, when Brotli became the default on a new server release, or when a CDN added Zstandard support — the affected pages are updated and the review date is bumped.

What this site is not

This is not a benchmarking site, a news site, or a comparison-shopping destination. There are no "best of 2026" roundups, no sponsored placements in technical articles, and no affiliate links inside guidance content. The site does carry display advertising (see the Privacy Policy and Cookie Policy) so the technical content can stay free, but advertising is kept separate from editorial recommendations.

Scope and limitations

HTTP body compression is the topic. Adjacent areas — image and video codecs, font subsetting, HTTP/2 header compression with HPACK, HTTP/3 with QPACK — are mentioned where they intersect with Accept-Encoding behaviour, but they are not the focus. Pages will tell you when a question lives outside that scope and where to look instead.

Corrections and feedback

If you spot an error, an outdated default, or a configuration sample that no longer matches a current server release, the Contact page lists how to reach the site. Corrections are welcome and credited at the bottom of the affected page when published.

Start with the home page for the full topic map, or jump straight to a server guide: Nginx, Apache, IIS.