Gzip Compression Test

The Gzip Compression Test is a free tool that fetches any public page live and checks whether the server is actually compressing its response with gzip or Brotli — and if so, exactly how much that compression is saving in transfer size. Rather than just confirming a header is present, it compares the real transferred byte count against the uncompressed size to report a measured savings percentage, so you know precisely how much bandwidth compression is or isn't saving on that page.

It exists because compression is one of the highest-impact, lowest-effort speed fixes available, but it's also easy to assume is already handled when it isn't — a server migration, a CDN misconfiguration, or a new hosting environment can silently leave compression off without anything visibly breaking. Running this check confirms whether it's actually active right now, on the live page, rather than trusting that a setting configured once is still working today.

When you submit a URL, the tool fetches the page live and reads the Content-Encoding header to determine whether gzip or Brotli compression is active, along with the Content-Length header for the actual transferred byte count. It then separately measures the uncompressed size of the same content and calculates the real savings percentage from the difference between the two — a measured comparison rather than an estimate based on content type alone.

When a server uses chunked transfer encoding without a Content-Length header, the compressed size isn't known until the response finishes streaming, so the tool can confirm compression is enabled without reporting an exact byte-for-byte savings figure in that case. This reflects a single live fetch of the page at the moment you run the test, from our server rather than a visitor's own connection.

• Enable gzip or Brotli on your server rather than relying on defaults. Brotli typically compresses 15-20% smaller than gzip for the same content, so it's worth confirming which one — if either — is actually active.
• Compress every text-based asset, not just the main HTML document. CSS, JavaScript, JSON, and SVG files all benefit just as much and are easy to overlook when only the document response gets configured.
• Skip compressing files that are already compressed. JPGs, PNGs, videos, and most font formats gain little to nothing from gzip or Brotli and just waste server CPU running compression that won't shrink them further.
• Don't treat compression as a substitute for image optimization. Compression works on text-based responses — properly sized and formatted images still need their own separate optimization to meaningfully cut page weight.