Gzip / Brotli Compression Checker

Check whether a URL is served with gzip or Brotli compression. Enter an address and this tool fetches it advertising every common encoding, then reports the Content-Encoding the server chose, the compressed transfer size versus the uncompressed size, and the percentage saved. Text compression is one of the cheapest, highest-impact speed wins, and this confirms in seconds whether it is switched on.

How to use the Gzip / Brotli Compression Checker

Enter a URL and press Check compression. The tool requests the page with an Accept-Encoding of gzip, deflate and Brotli, then reports:

• Whether the response is compressed at all, and the Content-Encoding (gzip, br, deflate or zstd) the server chose.
• The transfer size on the wire versus the decompressed size.
• The saving as a percentage, so you can see how much bandwidth compression is cutting.

Point it at an HTML page, a CSS or JS file, or a JSON endpoint. Already-compressed binaries (images, video, woff2 fonts) are expected to come back uncompressed, which is correct and not a problem.

How HTTP compression works

HTTP compression shrinks a response before it is sent and the browser expands it on arrival. The negotiation is simple: the browser sends Accept-Encoding: gzip, deflate, br listing what it can decode, and the server replies with Content-Encoding: br (or gzip) naming what it actually used. The body travels compressed, so far fewer bytes cross the network.

The two encodings you will see almost everywhere are:

• gzip — the long-standing default, supported by every browser and server. Typically cuts text by 60-75%.
• Brotli (br) — newer, developed by Google, usually 15-25% smaller than gzip on the same content, and now supported by all modern browsers over HTTPS. It is the better choice where available.

Compression matters because it applies to exactly the files that dominate page weight on first load: HTML, CSS, JavaScript, JSON and SVG are all highly compressible text. Turning it on often halves transfer size with no change to the code, which directly improves load time — especially on slow or metered mobile connections. The one rule is to not compress already-compressed formats: JPEGs, PNGs, MP4s and woff2 fonts are packed already, and re-compressing them wastes CPU for no size gain, so servers correctly leave them as-is. If this tool shows a text resource coming back uncompressed, that is the easy win to chase; if it shows an image uncompressed, that is expected.

Common use cases

• Confirming compression is on — the quickest check that gzip or Brotli is enabled for your text assets.
• Comparing gzip vs Brotli — see which encoding a server serves and how much smaller it is.
• Auditing page weight — measure how many bytes compression is actually saving on a given resource.
• Debugging a CDN — verify the edge is compressing responses, not passing them through raw.
• Catching misconfiguration — find text resources accidentally served uncompressed.

gzip vs Brotli: which to use

• Use Brotli where you can. On the same file it is typically 15-25% smaller than gzip, and every modern browser supports it over HTTPS. Most servers and CDNs can serve Brotli to clients that accept it and fall back to gzip for the rest.
• Keep gzip as the fallback. It is universally supported and still a big win over no compression. A good setup offers both and lets the browser pick via Accept-Encoding.
• Pre-compress static files. Brotli at its highest level is slow to compress, so for static assets, compress once at build time and serve the stored .br / .gz file rather than compressing on every request.
• Set Vary: Accept-Encoding. So shared caches store the right variant per client. The result here shows the Vary header when present.