GZIP Compression Test - Check If Your Site Is Compressed

What Is a GZIP Compression Test?

Text-based files — HTML, CSS, JavaScript, JSON, SVG — compress extremely well, often to a quarter of their original size or less. Servers can compress these before sending, and every modern browser decompresses them automatically. The whole exchange is invisible: the page looks identical, but far fewer bytes crossed the network.

A compression test requests a page while advertising support for compression, then reports whether the server took the offer. This matters because compression is one of the few performance improvements that is both large and free. Enabling it costs a few lines of server configuration and typically cuts text payload by 60 to 80 percent, which shows up directly in load times on slower connections. The setting is carried in the Content-Encoding response header, which you can also inspect alongside the rest using the HTTP headers parser.

How to Use This Tool?

1. Enter the URL you want to test, including https://
2. Run the test
3. Review whether compression was applied and how much it saved

The tool sends the same Accept-Encoding header a browser would, so the result reflects what real visitors receive.

Understanding the Results

Compression enabled means the server returned a compressed response and named the method in the Content-Encoding header. The saving is the difference between the compressed transfer size and the original.

gzip is the long-established method, supported everywhere without exception. It remains a perfectly good default.

Brotli is newer and typically compresses text 15 to 20 percent smaller than gzip at equivalent settings. Every current browser supports it over HTTPS. Servers usually offer Brotli first and fall back to gzip for anything that does not support it.

No compression means the response arrived uncompressed. On a text resource, this is worth fixing. On images, video, or already-compressed archives, it is expected and correct — those formats are compressed already, and running them through gzip adds CPU cost while saving nothing.

A small or negative saving on a tiny file is normal. Compression carries a small overhead, so files under roughly one kilobyte can come out slightly larger. Most server configurations set a minimum size threshold for exactly this reason.

Partial compression is the case people miss. A server can compress HTML while leaving CSS and JavaScript untouched, because the configuration lists MIME types explicitly and someone omitted a few. Testing only the page URL will not reveal it — test a stylesheet and a script file directly as well.

When Is This Tool Useful?

• Confirming compression is active after changing server or hosting configuration
• Checking whether a CDN is compressing at the edge or passing responses through untouched
• Diagnosing why a page transfers more data than its content would suggest
• Verifying that CSS and JavaScript are compressed, not just the HTML document
• Checking a site before a performance audit, since uncompressed text inflates every other metric
• Confirming the server responds correctly at all before investigating performance — if the page will not load, check whether the site is up first

What This Tool Does Not Do

The test covers one URL at a time. A result showing compressed HTML says nothing about the stylesheets, scripts, and fonts that page loads, and those are frequently where the missing configuration sits.

The result also reflects what this server received. A CDN may compress for some regions and not others, or apply different rules to cached and uncached responses. A test run once, from one location, is a sample rather than a guarantee.

Compression is also only one part of transfer size. A page can be perfectly compressed and still be slow because it ships far more code than it needs. Compression reduces the cost of what you send; it does not reduce what you chose to send.

Frequently Asked Questions

How do I check if gzip is enabled on my website?

Enter the URL above and run the test. The tool requests the page with compression enabled and reports whether the server responded with a compressed version, along with the original and compressed sizes. If compression is off, the Content-Encoding header is simply absent from the response.

How do I check whether Brotli is enabled instead of gzip?

The same test shows it. A server offering Brotli returns Content-Encoding: br, while gzip returns gzip. Most servers support both and pick whichever the requesting browser advertises, so seeing one does not mean the other is unavailable.

How much smaller should my files be after compression?

Text compresses well — HTML, CSS, JavaScript and JSON typically drop by 70 to 80 percent. If a text file is only a few percent smaller, compression is either not applied to that file type or the file is too small for it to matter. Anything already compressed will barely change.

How do I enable gzip compression on my server?

 On Apache, enable mod_deflate and list the MIME types to compress. On Nginx, set gzip on along with gzip_types. On shared hosting, it is usually a toggle in the control panel. After changing it, retest rather than assuming — the setting and the result often disagree.

Should I use gzip or Brotli?

Brotli where available, gzip as the fallback. Brotli produces smaller text output, and every current browser supports it over HTTPS. Most server configurations offer both and negotiate automatically, so this is rarely an either-or decision.

Why are my images not compressed?

They already are. JPEG, PNG, WebP, and video formats carry their own compression, and passing them through gzip costs processing time while saving almost nothing. Compression settings should target text formats only.

My HTML is compressed, but my CSS is not — why?

Server compression rules list MIME types explicitly, and text/css or application/javascript is often missing from the list. Add the missing types to the configuration and retest each file type directly rather than only the page.

Does compression affect SEO?

Indirectly, through page speed. Faster loading improves the Core Web Vitals that feed into ranking, and reduces the chance of visitors abandoning the page. Compression itself is not a ranking factor, but its effect on load time matters.