--- title: Free Gzip Compression Test description: Test whether a site serves gzip or Brotli-compressed responses — the Content-Encoding it negotiates, the compressed and uncompressed sizes and the bandwidth saved. Find the origin or CDN path that quietly serves uncompressed HTML, and see how much a page would shrink. canonical: https://watchfor.io/gzip-test --- [Back to all free tools](/free-tools) # Gzip Compression Test Test whether a site serves gzip or Brotli-compressed responses — the Content-Encoding it negotiates, the compressed and uncompressed sizes and the bandwidth saved. Find the origin or CDN path that quietly serves uncompressed HTML, and see how much a page would shrink. Result No result yet Enter the inputs above and press Run. Results appear here in a moment. Monitor this 24/7 — get alerts on the first failure. [Start free](/auth/sign-up) Only run these tools against systems you own or are authorized to test. Using them to scan or probe systems without permission violates our [Terms](/legal/terms). ## What is Gzip Compression Test ? HTTP compression shrinks text responses — HTML, CSS, JavaScript, JSON, SVG — by 60–80% before they cross the network. The browser announces what it can decode in Accept-Encoding: gzip, deflate, br, zstd ; the server picks one and says so in Content-Encoding . Gzip has been universal since the 1990s and is the safe baseline; Brotli compresses text 15–20% smaller still and is supported by every current browser. A site serving neither is sending three to five times more bytes than it needs to, on every page, to everyone. This test requests a page from a real probe with a browser-like Accept-Encoding and reports which encoding the server actually chose, the compressed and uncompressed sizes, and the bandwidth saved — or not. It catches the origin that has compression off, the CDN path that doesn't compress a content type, and the reverse proxy that strips Accept-Encoding on its way to the backend. ## How it works The same negotiation a browser does, with the numbers kept: - 1 Request with `Accept-Encoding` — The probe offers br and gzip , the way Chrome and Firefox do. A server that supports both should pick Brotli; one that supports only gzip picks gzip; one with compression off sends identity . - 2 Read `Content-Encoding` — The header on the response says what was applied. Missing or identity means uncompressed. Vary: Accept-Encoding should accompany it so caches keep the variants apart. - 3 Measure — Bytes on the wire versus bytes after decoding, and the ratio. A 120 KB HTML page arriving as 22 KB is working as intended. Compression applies per content type — the HTML may be compressed while the JSON API or the SVG icons are not. Test the URLs that matter, not just the homepage. ## When you'd use it ### Page speed audit Lighthouse flags "Enable text compression" as one of the largest wins. This test tells you which layer is at fault: origin, proxy or CDN. ### After changing hosting or CDN The old host compressed; the new nginx has gzip off by default for everything but text/html . Test CSS and JS URLs, not only the page. ### API responses JSON compresses extremely well and often isn't compressed at all because the API framework never enabled it. A 400 KB list endpoint at 40 KB is a mobile-user experience upgrade for one config line. ### Verifying Brotli You enabled Brotli. Is it being served, or does the CDN only compress with gzip on the edge? The Content-Encoding value settles it. ## Reading the result ### Content-Encoding br (Brotli) is best for text, gzip is fine, zstd is new and good, nothing means the server declined. Images, video and already-compressed files ( .woff2 , .zip ) should not be re-compressed — that's correct, not a finding. ### Compressed vs original size The savings. Below 20–30% for HTML or JS usually means something is off — minified code still compresses 70%+. ### Vary: Accept-Encoding Tells caches that the response differs by encoding. Without it a cache might hand a gzip body to a client that didn't ask for one, or the reverse. ### Small responses Compressing a 200-byte response can make it larger; servers skip it below a threshold (nginx gzip_min_length ). Not an error. ## Check it yourself curl -sI -H 'Accept-Encoding: gzip, br' https://example.com | grep -i content-encoding Compare curl -s https://example.com | wc -c with curl -s -H 'Accept-Encoding: gzip' https://example.com | wc -c for the sizes. ## Common pitfalls ### Compression enabled for `text/html` only nginx's gzip_types default is exactly that. CSS, JS, JSON, SVG and XML need to be listed explicitly. Apache's mod_deflate and Caddy's encode have similar lists. ### A proxy that drops `Accept-Encoding` Some load balancers and WAFs strip the header before forwarding, so the origin never compresses and the proxy doesn't either. The test from outside shows the net result. ### Compressing with TLS and reflecting secrets (BREACH) Compressing a response that mixes attacker-controlled input with a secret (a CSRF token) leaks the secret to a side-channel attacker. Modern mitigations (per-request token masking, SameSite cookies) handle it; don't disable compression site-wide because of it. ## Run Gzip Compression Test on every change, not just once. Get alerts the moment something breaks — across HTTP, DNS, SSL, RDAP, ping, blacklist and more. Free forever for 10 monitors. No card. [Start free](/auth/sign-up) ## Frequently asked questions Gzip or Brotli — which should I use? Both. Serve Brotli to clients that accept it (all modern browsers) and gzip to the rest. Brotli produces 15–20% smaller text at similar decode speed; pre-compress static assets at the highest level and use a moderate level for dynamic responses. How do I enable gzip in nginx? gzip on; gzip_types text/css application/javascript application/json image/svg+xml text/xml application/xml; gzip_min_length 256; gzip_vary on; in the http block, then reload and re-test. Why is Content-Encoding missing on my images? Correct behaviour. JPEG, PNG, WebP, MP4 and WOFF2 are already compressed; gzip would add CPU time and bytes. Only text-like types should be compressed. Does compression slow the server down? Slightly, and far less than the network time it saves. For static files, pre-compress at build time ( .gz / .br alongside the original) and serve them directly — zero runtime cost. Is deflate the same as gzip? Nearly — gzip is deflate with a header and checksum. Browsers accept both; gzip is the one to send because some old proxies mishandled raw deflate . ## Related web tools - [Brotli CheckerCheck whether a site serves Brotli-compressed responses (Content-Encoding: br) for faster page loads.](/brotli-checker) - [MCP Server CheckerTest a Model Context Protocol server: initialize handshake, protocol version, capabilities and the full tool inventory.](/mcp-server-checker) - [SSL Certificate CheckInspect certificate validity, expiry, SANs, issuer and chain trust.](/ssl-checker) - [SSL/TLS GradeGrade a server's TLS config A+ to F — protocols, ciphers, forward secrecy, post-quantum, HSTS and certificate, with the exact reasons.](/ssl-grade-checker) --- Canonical page: https://watchfor.io/gzip-test · Site guide: https://watchfor.io/llms.txt