GZIP Compression Test

Enter a website or the address of a single file, such as a page, a stylesheet or a script, and click Test URL. The test asks the server for it with gzip, Brotli and Zstandard separately, then shows:

• Which method browsers actually get
• The real size before and after compression
• How much each method saves

If compression is off, the result tells you how much you'd save and gives you the lines to turn it on for nginx or Apache.

The test follows redirects and reports the final URL, status code, protocol and response time. It also flags common mistakes, like a page compressed twice, a weak compression level or a missing Vary header.

Example: google.com

What browsers get. Google supports both gzip and Brotli, and sends Brotli to browsers that accept it, which is nearly all of them. The Content-Encoding: br line in the response details confirms it. Every browser tells the server which methods it can decode, and the server picks one.

Brotli is only slightly smaller here. It beats gzip by under 3 KB, about 3%. Brotli's advantage depends heavily on the compression level. Pages built on the fly are usually compressed at a moderate level to keep responses fast. Static files compressed ahead of time at the maximum level show a much bigger gap. For jQuery, the gap is about 17% (see the JS Minifier page).

The redirect. google.com answered with a 301 redirect to https://www.google.com/, and the test measured that final page. Test the address your visitors actually land on, since a redirect response itself is tiny.

The Vary warning. Google's response doesn't include Vary: Accept-Encoding. That header tells caches that the same URL comes in different versions depending on what the browser can decode. Without it, a shared cache, such as a CDN or a company proxy, could store the Brotli copy and hand it to a client that can't read Brotli.

For pages no shared cache stores, such as personalised pages marked Cache-Control: private, the missing header does no harm. For anything served through a CDN or proxy, add it.

Why compression matters

HTML, CSS, JavaScript, JSON and SVG are plain text with lots of repetition, and compression typically shrinks them by 60 to 80 percent. That's less data to download on every visit, which matters most on mobile connections.

PageSpeed Insights and Lighthouse flag text files that aren't compressed. Google's own crawlers support gzip, deflate and Brotli, so compression also saves bandwidth every time your site is crawled.

Compression and minification work best together. Minifying removes what the code doesn't need, and compression shrinks what's left. The JS Minifier, CSS Minifier and HTML Minifier handle the first step.

Turning compression on

nginx. Add these lines to the http block of your configuration, then reload nginx

gzip on;
gzip_comp_level 6;
gzip_vary on;
gzip_types text/plain text/css text/xml text/javascript application/javascript application/json application/xml image/svg+xml font/ttf font/otf;

HTML is always included once gzip is on, so it doesn't need to be listed. gzip_vary on adds the Vary header. Brotli needs the separate ngx_brotli module, which standard nginx packages don't include.

Apache. With mod_deflate enabled, add this to your configuration or .htaccess

<IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/html text/plain text/css text/xml text/javascript application/javascript application/json application/xml image/svg+xml font/ttf font/otf
</IfModule>

Shared hosting and CDNs.

• In cPanel, the Optimize Website option switches on compression.
• LiteSpeed servers usually compress by default.
• Cloudflare and most other CDNs compress text automatically, with Brotli for browsers that support it.

Whatever you change, run the test again afterwards. Test a stylesheet and a script too, not only the home page, because static files are often served by different rules than pages.

Files that don't need compression

Images (JPG, PNG, WebP, AVIF), video, audio, WOFF and WOFF2 fonts, and ZIP or other archives are already compressed. Compressing them again saves almost nothing and only costs server time, so a "not compressed" result for these files is correct.

The exceptions are SVG images, which are text and shrink well, and older TTF or OTF font files, which aren't compressed.

Mistakes the test catches

Compressed twice. This usually happens when the application compresses its output (for example, PHP's zlib.output_compression) and the web server compresses it again. The browser undoes one layer and gets compressed bytes instead of a page. You'll see garbled characters or an error like ERR_CONTENT_DECODING_FAILED. Turn compression off in one of the two places.

A weak compression level. nginx's default gzip level is 1, the lightest. Levels 5 or 6 produce noticeably smaller files for little extra CPU work, while going above 6 barely helps.

A missing Vary header. See the example above.

FAQ

Which should I enable: gzip, Brotli or Zstandard?

Enable gzip as the baseline, since every browser and client supports it. Add Brotli on top for modern browsers. Zstandard is the newest. Chrome, Edge and Firefox support it, and some CDNs offer it, but it's optional for now. Servers always fall back to gzip for clients that can't use anything newer.

Why does my site get gzip and not Brotli?

Either the server or CDN doesn't have Brotli enabled, or the site isn't on HTTPS. Browsers only offer to accept Brotli over HTTPS connections.

Compression is on, so why is the saving small?

Either the file is already compressed (an image, font or archive) or it's very small. Files under a few hundred bytes barely shrink, which is why the nginx example skips anything under 256 bytes.

Does compression slow down my server?

Not noticeably at levels 5 or 6. For static files you can avoid the cost entirely by storing pre-compressed .gz or .br copies next to the originals and letting the server send those. nginx does this with gzip_static on.

Where can I see all of a page's headers?

The HTTP Headers Parser shows every response header. The Website Technologies Check also reports which compression methods a site supports, alongside its server and security setup.