Vary Inspect

What does this tool do?

Parse the Vary header and list which request headers the response varies on.

Useful for diagnosing cache misses/over-caching, CDN cache mixing, and unstable CORS behavior.

Vary basics (quick)

• Vary indicates that the response content depends on specific request headers.
• Caches (browser/proxy/CDN) use Vary to store separate variants per request header values.
• Designing Vary is essentially designing your cache key.

Syntax (how to read)

Vary is a comma-separated list of header names, or a special value *.

• Vary: Accept-Encoding
• Vary: Origin
• Vary: Accept-Encoding, Origin
• Vary: *

Examples (copy-paste mental model)

In practice, pasting the whole response headers and extracting Vary is the fastest workflow.

• Static assets with compression: Vary: Accept-Encoding
• CORS allowlist by origin: Vary: Origin
• Localized HTML: Vary: Accept-Language (beware fragmentation)

If you see Vary: *, it often explains why shared caching barely works—check it first.

Why it matters (prevent cache-key bugs)

If Vary is missing, a response generated under different conditions may be reused for the same URL, causing content mixing or even security issues.

If you overuse Vary, you create too many variants (cache fragmentation), reducing hit ratio and increasing latency/cost.

Design approach (keep Vary minimal; split by URL)

Vary is powerful, but each added dimension fragments caches. If variants are stable, splitting by URL/path is often more operationally reliable.

• Language: split into /ja/ /en/ (avoid varying by Accept-Language)
• Device variants: prefer responsive/same HTML (avoid varying by User-Agent)
• Auth: if it varies by Authorization/Cookie, don’t assume shared caching (private/no-store, etc.)

Typical pattern: Vary: Accept-Encoding

Even for the same URL, different encodings (br/gzip/identity) produce different bytes. If you serve compression, Vary: Accept-Encoding is a baseline.

• Without it: caches can mix compressed/uncompressed variants and break clients
• With it: caches store per-encoding variants (lower hit ratio but correct)

Use Client Hints instead of User-Agent?

Even if you need device variants, varying on User-Agent often fragments caches too much. Client Hints (e.g., Sec-CH-UA-Platform) can be an alternative, but it still increases variants and costs.

A safer order: try URL split or single responsive output first; add Vary as a last resort.

Glossary (terms used on this page)

• Variant: A distinct version of a response for the same URL under different request conditions.
• Cache key: The set of conditions that define cache identity (influenced by Vary and CDN cache-key configuration).
• Shared cache: CDN/proxy caches shared across users; mixing variants can be dangerous.
• Fragmentation: Splitting caches into many variants, reducing hit ratio.

Common Vary values

• Accept-Encoding: separates gzip/br variants (important for static assets)
• Origin: when CORS responses vary by Origin
• Accept-Language: when content varies by language (high fragmentation risk)
• User-Agent: device variants (generally discouraged; huge fragmentation)

Security/incident patterns caused by missing Vary

Vary is not only about performance—it can prevent misdelivery (serving a variant generated for different conditions). The more you rely on shared caches, the bigger the impact.

• CORS header mixing: dynamic Access-Control-Allow-Origin without Vary: Origin
• Auth/personal data mixing: shared caching for responses varying by Cookie/Authorization
• Compression mismatch: encoding variants without Vary

Mitigation is not only “add Vary”: also design Cache-Control (private/no-store) and CDN cache-key/bypass rules.

Notes for CDNs/shared caches

Vary affects not only browsers but also CDN/proxy cache hit ratios. Cookie/Authorization/Origin are especially sensitive: mixing is dangerous, but varying increases fragmentation.

• Responses intended for shared caching should not include per-user data
• If CORS is dynamic, prioritize checking Vary: Origin
• Vary: * often makes shared caching effectively unusable

CORS and Vary: Origin

If you dynamically return Access-Control-Allow-Origin based on the request Origin, missing Vary: Origin can cause cached CORS headers to be served to the wrong origin.

This becomes more critical with CDNs, so it’s a top check for CORS troubleshooting.

What does Vary: * mean?

Vary: * means “the variation can’t be expressed as a list of request headers” and makes reuse difficult for shared caches (CDN/proxy).

If it appears unintentionally, it commonly explains “why caching doesn’t work”.

Debugging workflow (recommended)

• Paste response headers into Response Headers Parser and check Vary
• Split Vary here to understand the number/type of variation headers
• Also verify Cache-Control / ETag / Content-Type to confirm intended caching design

Common pitfalls

• Dynamic CORS headers without Vary: Origin
• Cache fragmentation from Vary: User-Agent / Accept-Language
• Serving compressed variants without Vary: Accept-Encoding
• Varying on Cookie/Authorization while expecting shared caching

Troubleshooting checklist by symptom

• CDN content mixing: suspect missing Vary (especially Origin / Accept-Encoding)
• Caching not working: check Vary: *, too many Vary fields, Cache-Control, and CDN cache key config
• Unstable API CORS: if Access-Control-Allow-Origin is dynamic, prioritize Vary: Origin
• Language not switching/mixing: check Accept-Language variation and consider URL-based separation

How to test (diff variants with curl)

The fastest way to understand Vary is to hit the same URL with different request headers. Examples below (replace the URL).

• Encoding: curl -I -H "Accept-Encoding: br" https://example.com/asset.js
• Encoding (compare): curl -I -H "Accept-Encoding: gzip" https://example.com/asset.js
• CORS: curl -I -H "Origin: https://a.example" https://example.com/api
• Language: curl -I -H "Accept-Language: ja" https://example.com/

Check whether the returned Vary aligns with the headers you changed (missing vs excessive variation).

Related tools

• Response Headers Parser
• Cache-Control Inspect
• ETag Inspect
• CORS Checklist
• Content-Type Inspect

Recommendations (practical)

• Keep Vary minimal to avoid cache fragmentation
• Compression typically varies on Accept-Encoding
• Avoid Vary: * (effectively disables caching)

What this tool does

• Split and list Vary fields
• Normalize duplicates and casing differences
• Help spot risky/high-fragmentation variation (Cookie/Authorization/User-Agent, etc.)
• Detect Vary: *

Operational notes

• Cache behavior changes across browser, CDN, and proxy layers, so compare captures from the same observation point.
• Header-only diagnosis may be insufficient. Also review application cache invalidation strategy and key design.

Referenced specs

• RFC 9110 (HTTP Semantics)
• RFC 9111 (HTTP Caching)
• MDN: Vary

FAQ

References

1. RFC 9110
2. RFC 9111
3. MDN: Vary
4. MDN: HTTP caching
5. MDN: CORS

Next to view (diagnostic order)

These links are generated from site_map rules in recommended diagnostic order.

1. Last-Modified Inspect — Parse Last-Modified and If-Modified-Since
2. ETag Inspect — Parse ETag and If-None-Match consistency
3. Expires Inspect — Parse Expires and Date to inspect freshness behavior
4. Cache-Control Inspect — Parse and interpret Cache-Control directives
5. Accept-Encoding Inspect — Parse Accept-Encoding and inspect compression negotiation
6. Content-Encoding Inspect — Parse Content-Encoding to verify applied compression
7. Transfer-Encoding Inspect — Parse Transfer-Encoding and inspect transfer mode
8. Content-Length Inspect — Parse Content-Length and inspect size consistency

Same-theme links

Compression/Transfer

Use Accept/Content/Transfer-Encoding plus Vary to isolate compression mismatches

• Accept-Encoding Inspect — Parse Accept-Encoding and inspect compression negotiation
• Content-Encoding Inspect — Parse Content-Encoding to verify applied compression
• Transfer-Encoding Inspect — Parse Transfer-Encoding and inspect transfer mode
• Content-Length Inspect — Parse Content-Length and inspect size consistency