Compression & Encoding Checker
Requests a URL with identity, gzip, Brotli, and Zstandard Accept-Encoding values, measures the real transferred and decoded sizes, and verifies each encoded response actually decodes.
Based on: RFC 9110 — HTTP Semantics
About this validation
Requests a URL with identity, gzip, Brotli, and Zstandard Accept-Encoding values via a direct, non-decompressing HTTP client, then measures real transfer sizes and verifies each declared Content-Encoding actually decodes, per RFC 9110's content-encoding semantics.
- Protocol / standard:
- Rules reviewed:
- Sep 1, 2026
Standards and vendor-documented behavior can change. This reflects the source as last reviewed above, not a permanent guarantee.
What This Test Checks
Talks to the server directly (bypassing the browser's automatic decompression) to capture the real, still-encoded bytes for each Accept-Encoding value, then decodes them itself to compute an accurate compression ratio and confirm the declared Content-Encoding is actually correct -- flagging a malformed or undecodable response, a missing Vary header when representations genuinely differ by encoding, and a charset mismatch between the Content-Type header and the document itself.
FAQ
Why does this need a different engine than the other tools?
Browsers and Node's built-in fetch() automatically decompress gzip/Brotli/Zstandard responses and never expose the original compressed bytes. This tool talks to the server directly so it can measure the real transferred size and verify the encoded body actually decodes correctly.
Is it a problem if Brotli or Zstandard isn't supported?
No. Not every server or CDN supports every encoding, and that's not treated as an error here -- only a response that claims an encoding it doesn't actually deliver correctly is flagged.
What does 'malformed gzip' mean?
The server declared Content-Encoding: gzip, but the bytes it returned don't decode as valid gzip data. A browser receiving this would fail to render the page at all.