Content-Encoding Inspect

Parse and diagnose HTTP headers and routing signals in your browser. No input is sent to a server. Use it for first-pass observation-gap 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 Content-Encoding or Response Headers and click “Parse”. It summarizes applied encodings and checks.

Notes (this tool)

  • Accepts Content-Encoding: header lines (multi-line paste is OK).
  • When multiple encodings are listed, they are treated as a stacked order.

About this page

What does this tool do?

Split Content-Encoding to list applied encodings (br/gzip/deflate/zstd, etc.).

Useful for diagnosing missing compression, decode failures, and cache mixing.

Basics (Content-Encoding vs Accept-Encoding)

  • Content-Encoding is the encoding actually used.
  • Accept-Encoding lists what the client accepts.
  • When serving compressed responses, Vary: Accept-Encoding is a baseline.

Multiple encodings (stacking)

Content-Encoding can list multiple values. It is typically interpreted as applied in order (right to left).

  • Example: Content-Encoding: br, gzip → gzip applied first, then br.
  • Deep stacks can cause compatibility/decoding issues.

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 (usually not listed)

Caching and Vary: Accept-Encoding

If Content-Encoding can vary by client, Vary: Accept-Encoding is essential to prevent cache mixing.

  • Missing Vary can mix different encodings
  • CDNs typically vary cache by Accept-Encoding

Common pitfalls

  • Returning an encoding not listed in Accept-Encoding
  • Content-Encoding with mismatched Content-Length (pre/post-compression mix)
  • Recompressing already-compressed files increases size
  • Incorrect stacking order breaks decoding

Debugging workflow (recommended)

  • Extract Content-Encoding via Response Headers Parser
  • Check client-accepted encodings with Accept-Encoding Inspect
  • Verify Vary: Accept-Encoding with Vary Inspect
  • Accept-Encoding Inspect
  • Vary Inspect
  • Response Headers Parser
  • Request Headers Parser
  • Cache-Control Inspect
  • Age Inspect
  • Via Inspect

What this tool does

  • Parse Content-Encoding and list application order
  • Highlight common pitfalls
  • Highlight related headers to verify

Operational notes

  • Intermediaries may rewrite headers. Compare captures from equivalent points.
  • Confirm final decisions with server logs and configuration such as trusted proxy and routing.

Referenced specs

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

FAQ

Is it a problem if Content-Encoding is missing?

It’s normal if the response is uncompressed. If you expect compression, check server/CDN settings.

Can I use br and gzip together?

Multiple encodings can be stacked, but a single encoding is more common for compatibility.

Is Content-Length pre- or post-compression?

With Content-Encoding, Content-Length is generally the compressed size.

References

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

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

  1. Transfer-Encoding Inspect — Parse Transfer-Encoding and inspect transfer mode
  2. Accept-Encoding Inspect — Parse Accept-Encoding and inspect compression negotiation
  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