b2KIT

Gzip Compression Tester

Check if a website serves gzip or brotli compressed responses with compression ratio and size savings display.

Tested tool guide Tested browser tools Checked August 16, 2026

What Gzip Compression Tester does and how it behaves

Gzip Compression Tester examines the response for one entered URL and reports whether its representation is sent with the HTTP gzip or br content coding. It pairs the detected coding with compressed and uncompressed byte counts, then summarizes the reduction as a ratio and size saving. The result concerns that particular resource and request, not the whole domain. A common surprise is that one site can compress an HTML document while leaving an image, API response, redirect, or very small resource uncompressed.

How the result is produced

1

Content coding detection

The entered URL selects a single response to inspect. A gzip result corresponds to the HTTP gzip content-coding token, while a Brotli result corresponds to br. If neither supported coding is reported, the result does not establish an uncompressed response: another content coding may be present, or cross-origin restrictions may prevent the browser from exposing enough response information to determine the coding.

2

Size comparison

The report places the compressed size beside the corresponding uncompressed size and turns their difference into a size saving and compression ratio. Those figures compare representations of the tested resource. They do not measure total page weight, rendering time, or the sizes of scripts, stylesheets, images, fonts, and other subresources that an HTML document may load.

Good uses

  • Checking a public HTML URL after a CDN configuration change to confirm whether it now arrives with Brotli or gzip and to quantify the reported byte reduction.
  • Comparing the same versioned JavaScript or CSS asset before and after enabling compression, using the displayed sizes to catch an origin or cache configuration that still serves an uncompressed variant.
  • Testing a JSON API endpoint whose network transfer looks unexpectedly large, then recording whether the sampled response has a content coding and how much smaller its compressed representation is.

Limits and checks

  • Treat the result as a sample of one URL at one time. Compression can vary by path, status code, content type, response size, cache state, CDN edge, and request conditions such as the accepted content codings.
  • Do not interpret an uncompressed result as automatic evidence of a fault. JPEG, PNG, ZIP, and many audio or video formats are already compressed, while encoding a very small response can add overhead instead of saving useful bytes.
  • The phrase compression ratio is used in both directions across software. Use the displayed compressed and uncompressed sizes to establish what this tester's ratio represents before comparing its number with a server dashboard, command-line utility, or another website test.

Common questions

Why does a URL show no gzip or Brotli even though the site uses compression?

Compression is negotiated and selected per response. The requested path may be tiny, already compressed, generated differently, served from another cache tier, or returned with an error or redirect. Test a compressible HTML, CSS, JavaScript, or JSON resource and make sure the status and final resource are the ones you intended to inspect.

Does testing upload the response contents?

No. The URL is handled in the browser and its response contents are not uploaded to a separate analysis service. The target website still receives the request, as it would during ordinary navigation, and network intermediaries may observe it. Cross-origin restrictions, authentication, consent screens, or bot defenses can also prevent a complete result.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools