---
title: Accept-Encoding
summary: null
url: >-
  https://www.fastly.com/documentation/reference/http/http-headers/Accept-Encoding
---

The `Accept-Encoding` request HTTP header indicates the content encoding (usually a compression algorithm) that the client can understand. The server uses content negotiation to select one of the proposal and informs the client of that choice with the `Content-Encoding` response header.

> **HINT:** `Accept`, `Accept-Encoding` and `Accept-Language` are designed to allow for [content negotiation](https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation).  For content negotiation to work properly on content served through Fastly, the `Vary` header must be correctly set.  See our blog post [Getting the most out of Vary with Fastly](https://www.fastly.com/blog/getting-most-out-vary-fastly) for a discussion of the best practices and patterns that you may find useful.

## Normalization

Fastly automatically normalizes the value of `Accept-Encoding` on inbound requests because it has a huge impact on cache performance when responses include `Vary: Accept-Encoding`.  

Compression support is one of the most common reasons to vary output based on a request header - so that compressed content can be delivered to clients that support it, and uncompressed to those that don't.  However, the number of possible permutations of `Accept-Encoding` on requests is large: for example, "deflate, gzip" and "gzip, deflate" are different strings but indicate support for the same compression standards.

The normalized header is set to a single encoding type, or none, and will reflect the best compression scheme supported by the browser.  Specifically, we run the following steps on inbound requests before invoking `vcl_recv`:

1. Set `Fastly-Orig-Accept-Encoding` to the value of `Accept-Encoding`.
2. If the `User-Agent` matches a pattern for browsers that have problems with compressed responses, remove the `Accept-Encoding` header.
3. Else if the `Accept-Encoding` header includes the string "gzip", set the entire value to the string "gzip"
4. Else if the `Accept-Encoding` header includes the string "deflate", set the entire value to the string "deflate"
5. Else remove the `Accept-Encoding` header

As part of the `# FASTLY recv` macro in `vcl_recv` (see [using VCL](https://www.fastly.com/documentation/guides/vcl/using/)) we run the following additional step for services that have brotli compression enabled:

1. If the `Accept-Encoding` header includes the string "br", set the entire value to the string "br".

An origin server that supports and generates compressed responses should include `Vary: Accept-Encoding` in all responses where compression was considered, whether or not the response was actually compressed.  When caching a response that contains such a `Vary` header, Fastly will only match it to future requests that carry the same `Accept-Encoding` header as the request that prompted the origin response.

If you prefer to normalize the value of `Accept-Encoding` yourself in a VCL service, see the `accept.encoding_lookup` function.  Be sure to perform your normalization using `req.http.Fastly-Orig-Accept-Encoding` as a source, and do it after the `#FASTLY recv` macro has executed.

If you prefer to handle `Accept-Encoding` yourself on your origin, you can ignore the normalization with:

```vcl
set req.http.Accept-Encoding = req.http.Fastly-Orig-Accept-Encoding;
```

## Interaction with compression at the edge

Fastly supports compressing HTTP responses at the edge, using both GZip and (where enabled on your service) Brotli.  This can be activated in our web interface or using the Fastly API.  It's also possible to construct the same behavior manually using VCL code.  See `beresp.gzip` and `beresp.brotli` for more details.

When content is compressed at the edge, it benefits from automatic normalization of `Accept-Encoding` in exactly the same way that origin-compressed content does.