Gzip Compression Checker

What this tool checks

This checker requests your URL with compression enabled and inspects the response headers. If the response includes Content-Encoding: gzip or br, the resource is compressed.

Gzip vs Brotli

Gzip is the most widely supported compression format on the web, especially for HTTP and older clients. Brotli generally compresses better on HTTPS, so many CDNs serve br over HTTPS and fall back to gzip when Brotli is not available.

How to read the headers

• Content-Encoding: gzip means the response body is compressed.
• Vary: Accept-Encoding tells caches to store separate compressed/uncompressed variants.
• Content-Type: Compression is typically applied to text assets like HTML, CSS, JS, JSON, and SVG.
• Content-Length: When present, it often reflects the compressed payload size.
• Cache-Control: Aggressive caching helps you benefit from compression more often.

Common reasons you may not see gzip

• The server or CDN only compresses specific MIME types.
• The response is already small, so compression is skipped.
• Brotli is enabled for HTTPS and gzip is used for HTTP.
• The origin is already sending compressed content, and the CDN avoids double compression.
• A cache is serving an older, uncompressed variant.

Best practices

• Enable compression at the origin and at the CDN edge.
• Prefer Brotli on HTTPS, but keep gzip as a fallback.
• Precompress large static assets and serve .gz versions when possible.
• Verify Content-Type is correct so text assets get compressed.
• Avoid compressing already-compressed binary assets (images, video, PDFs).

Quick checklist

1. Request the URL with Accept-Encoding: br, gzip.
2. Confirm Content-Encoding is present in the response.
3. Ensure Vary: Accept-Encoding is set for proper caching.
4. Verify the asset is text-based and worth compressing.