Vary

The HTTP Vary response header tells caches which request headers influenced the response, so the same URL gets stored and served correctly when different representations exist.

Table of Contents

Usage

A single URL often produces different responses depending on what the client sends. A server compressing with gzip for one client and Brotli for another serves two distinct representations of the same resource. The Vary header records which request headers caused the server to choose a particular representation, giving caches the information needed to store and match the right copy.

When a cache receives a request for a URL with a stored response, the cache compares the listed Vary headers between the new request and the stored one. If the values match, the cached response is valid. If they differ, the cache fetches a fresh response from the origin.

The most common values are Accept-Encoding (for Compression negotiation) and Accept (for content negotiation). Dynamic serving setups serving different HTML to mobile and desktop clients based on the User-Agent string add Vary: User-Agent to signal this variation.

The wildcard value * means every request is considered unique and effectively disables caching for the resource. This is rarely appropriate and most caches treat a Vary: * response as uncacheable.

Note

Google does not use the Vary header to understand mobile and desktop relationships for search indexing. The header is a caching mechanism, not a search signal. Sites using dynamic serving with Vary: User-Agent still benefit from correct cache behavior, but the header itself has no effect on how Google discovers or indexes mobile content. Google also advises against making m-dot URLs the canonical version despite mobile-first indexing, recommending responsive design as the preferred configuration.

Directives

Accept-Encoding

Indicates the response varies by the Accept-Encoding request header. Different Compression algorithms (gzip, br, zstd) produce different response bodies for the same resource. This is the most widely used Vary value.

Accept

Indicates the response varies by the Accept request header. Content negotiation delivers different media types (HTML, JSON, XML) from the same URL based on client preference.

Accept-Language

Indicates the response varies by the Accept-Language request header. Multilingual sites serving localized content from the same URL include this value.

User-Agent

Indicates the response varies by the User-Agent request header. Dynamic serving configurations deliver different HTML to mobile and desktop clients from the same URL.

* (wildcard)

The wildcard value signals the response varies by factors not captured in a request header. Caches treat this as uncacheable. Rarely used intentionally.

Example

A server compresses responses using the encoding requested by the client. The Vary: Accept-Encoding header tells intermediate caches to store separate copies for gzip and Brotli requests rather than serving a gzip-compressed response to a Brotli-capable client.

Vary: Accept-Encoding

A content negotiation setup delivers JSON or HTML from the same endpoint. The cache stores separate responses based on the Accept header value.

Vary: Accept

Multiple headers influencing the response are listed as a comma-separated value. Here the response depends on both the accepted encoding and the preferred language.

Vary: Accept-Encoding, Accept-Language

A dynamic serving configuration delivers different HTML to mobile and desktop user agents. The cache stores separate versions keyed by the full User-Agent string.

Vary: User-Agent

Pairing Vary with Cache-Control controls both what varies and how long each variant stays fresh.

Cache-Control: public, max-age=3600
Vary: Accept-Encoding

Takeaway

The Vary header tells caches which request headers produced a given response, enabling correct storage and retrieval of multiple representations at the same URL. Keeping the Vary list short and precise prevents unnecessary cache fragmentation.

See also

Last updated: March 11, 2026