Compression (gzip/brotli) Check

The compression check tool verifies in real time whether a server applies content compression such as gzip or brotli (br) to a given URL. Just like a browser, it sends an Accept-Encoding: gzip, br, deflateheader and then reads the response's Content-Encoding value to show which compression, if any, is in use.

Text-based assets (HTML, CSS, JavaScript, JSON, and so on) shrink dramatically once compression is enabled, improving load times and Core Web Vitals. If compression is missing, you are leaving one of the easiest, highest-impact optimizations on the table. Enter a URL to see the applied encoding alongside the Content-Type and Vary headers. To see how heavy the page is, use the page weight analyzer, and to check whether the server responds quickly, the response time test.

gzip vs brotli

gzip is the standard compression method supported by virtually every server and browser. brotli (br) is a newer algorithm from Google that typically compresses the same text 15-25% smaller than gzip. Most modern browsers support brotli over HTTPS, so a good setup serves brotli for static text assets while keeping gzip enabled for dynamic responses and older clients.

Which assets to compress

• Compress: text-based assets such as HTML, CSS, JavaScript, JSON, SVG and XML
• Skip: already-compressed binaries like JPEG, PNG, WebP and MP4 (recompressing wastes CPU for almost no gain)
• Vary header: compressed responses should send Vary: Accept-Encoding so caches and proxies keep compressed and uncompressed variants separate.

Differences behind proxies and HTTP/2

Intermediaries such as CDNs, reverse proxies and load balancers may handle compression themselves or decompress and recompress responses, so the origin's configuration can differ from what is actually returned. Header presentation can also vary by tool under HTTP/2 and HTTP/3. This tool reports the Content-Encoding seen on the final response, so for sites behind a CDN you are looking at what the edge returned.

Content-Encoding values, quick reference

Here are the tokens you will actually see in the Content-Encoding header and what each means. When multiple codings are stacked they appear comma-separated, e.g. br, gzip, read in the order applied.

Reading a real response

Say you check https://example.com/app.js(a 320 KB JavaScript file) and the response headers come back like this:

• Content-Type: application/javascript — a text asset, so it is a valid compression target.
• Content-Encoding: br — Brotli is applied. The tool reads this value and reports "compressed (br)".
• Vary: Accept-Encoding — correctly set so caches store compressed and uncompressed variants separately.

In this case the transferred size typically drops to around 70 KB (roughly 78% smaller). Conversely, an empty Content-Encoding paired with Content-Type: application/javascript is a clear signal that simply enabling compression would yield that same reduction immediately.

Common pitfall

• Assuming the whole site is compressed because the HTML is: the root document may be compressed while JS/CSS bundles served from a separate CDN or storage bucket are not. Test the URL of your heaviest asset directly.
• Trying to recompress already-compressed files: a missing Content-Encoding on .jpg, .png or .woff2 looks like a problem but is normal — recompressing them only burns CPU for no gain.