Accept-Encoding Inspect

This page helps you quickly compare client encoding preferences against server behavior when the same URL returns different compression variants across environments.

Status

Runs in your browser. No input is sent to a server. Use this as a first-pass diagnostic step.

How to use

Paste Accept-Encoding or Response Headers and click “Parse”. It summarizes encodings and q priorities.

Notes (this tool)

  • Accepts Accept-Encoding: header lines (multi-line paste is OK).
  • q is a priority from 0.0 to 1.0. q=0 means “not acceptable”.

About this page

What does this tool do?

Split Accept-Encoding to list accepted compression encodings (br/gzip/deflate/zstd, etc.) and their q priorities.

Useful for diagnosing issues like compression not working, CDN cache mixing, or variant content at the same URL.

Basics (Accept-Encoding vs Content-Encoding)

  • Accept-Encoding indicates which encodings the client can accept.
  • Content-Encoding is the encoding the server actually used.
  • If you serve compressed responses, Vary: Accept-Encoding is a baseline.

How to read q values (priorities)

  • q=1.0 is highest priority; smaller q means lower priority.
  • q=0 means “not acceptable”.
  • If omitted, q is typically treated as 1.0.

Input examples

  • Accept-Encoding: br, gzip, deflate
  • Accept-Encoding: gzip;q=1.0, br;q=0.8, *;q=0
  • Paste full Response Headers

Common encodings

  • br: Brotli (common for HTTPS and static assets)
  • gzip: classic, widely compatible
  • zstd: fast and efficient, but support varies
  • deflate: legacy with implementation quirks
  • identity: no compression (can be implicit)
  • *: any other encoding

Caching and Vary: Accept-Encoding

Because the byte representation changes by encoding, caches must vary by Accept-Encoding.

  • Without Vary, caches can mix variants (e.g., br served to gzip-only clients).
  • Too much Vary fragments caches; keep it minimal.

Common pitfalls

  • Accept-Encoding present but no Content-Encoding (no compression)
  • Missing Vary: Accept-Encoding causing CDN cache mixing
  • Recompressing already compressed files increases size/CPU
  • deflate compatibility issues causing client decode failures

Debugging workflow (recommended)

  • Check Accept-Encoding via Request Headers Parser
  • Check Content-Encoding and Vary via Response Headers Parser
  • Use this tool to summarize q values and acceptance
  • Vary Inspect
  • Response Headers Parser
  • Request Headers Parser
  • Content-Type Inspect
  • Cache-Control Inspect
  • Age Inspect
  • Via Inspect

What this tool does

  • Parse Accept-Encoding and summarize q priorities
  • List acceptable encodings (including identity/*)
  • Highlight related headers to verify

Operational notes

  • The same string can be interpreted differently by context. Prioritize destination specifications.
  • Watch for upstream auto-conversion such as spaces, line breaks, and URL decoding.

Referenced specs

  • RFC 9110 (HTTP Semantics)
  • RFC 9111 (HTTP Caching)
  • MDN: Accept-Encoding

FAQ

Does it work if Accept-Encoding is empty?

Most clients send it, but if not, servers typically respond without compression (identity).

Is Vary: Accept-Encoding required?

If the same URL can return different encodings, it should be included to prevent cache mixing.

Can a server return br even if it’s not listed?

Servers should honor the client list. Returning an unsupported encoding can break clients.

References

  1. RFC 9110
  2. RFC 9111
  3. MDN: Accept-Encoding
  4. MDN: Content-Encoding
  5. MDN: Vary

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

  1. Content-Encoding Inspect — Parse Content-Encoding to verify applied compression
  2. Transfer-Encoding Inspect — Parse Transfer-Encoding and inspect transfer mode
  3. Content-Length Inspect — Parse Content-Length and inspect size consistency
  4. Vary Inspect — Parse Vary and visualize cache variation keys

Compression/Transfer

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