Accept-Encoding Inspect

Run parsing, conversion, and validation in your browser. No input is sent to a server. Use it for first-pass format troubleshooting.

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