Check Gzip CompressionTest Gzip and Brotli on Any URL

The Kwebby tool checks gzip compression by fetching your page and reading the Content-Encoding the server sends back. Enter a URL, click Check, and the result card says whether the response is compressed and with which format. This guide explains each line of the result, why compression matters, and how to turn it on if the test comes back negative. For more server tests, browse our Free Developer Tools.

Key Takeaways

• The Kwebby tool reports whether a URL is served with Gzip, Brotli, Deflate or Zstandard compression, or none.
• The result shows the HTTP status, the encoding, the bytes transferred, the uncompressed size, the percentage saved, the content type and the Vary header.
• If the server answers with an error or block page (any status outside 2xx), the tool marks the result Inconclusive instead of reporting compression as off.
• Lighthouse recommends Brotli when the browser supports it and gzip as a fallback.
• Google's crawlers support gzip, deflate and Brotli.
• The tool is free and needs no account.

What Is the Kwebby Gzip Compression Checker?

The Kwebby gzip compression checker is a free online tool that tests whether a web server compresses the response for a URL. You enter an address, the tool requests it with the header Accept-Encoding: gzip, deflate, br, zstd, and the result tells you the encoding it received and how many bytes it saved.

Compression shrinks text such as HTML, CSS and JavaScript before it travels to the browser. The server marks the response with a Content-Encoding header, and the browser unpacks it. MDN's Content-Encoding reference lists the values gzip, deflate, br (Brotli) and zstd (Zstandard).

Key Features and How It Works

The result has a status card on top and eight detail rows below it.

A Clear Status Card

The card turns green with a message such as "Gzip Compression Enabled" or "Brotli Compression Enabled" when the response is compressed, and red with "Compression Not Enabled" when it is not. Deflate and Zstandard get their own labels too. When the server returns a status outside the 2xx range, such as 403 from a firewall, the card turns amber and reads "Inconclusive", because the tool received an error page instead of your real page.

Eight Detail Rows

• HTTP Status. The response code, such as 200.
• Encoding. The compression format, or None.
• Bytes Transferred. The size of the body as it arrived over the network, before decompression. The tool stops reading at 15 MB.
• Uncompressed Size. The size after the tool decompresses the body.
• Saved by Compression. The percentage of bytes the compression removed.
• Content Type. The media type, such as text/html; charset=utf-8.
• Vary Header. The server's Vary value, or "Not set".
• Accept-Encoding Sent. The encodings the tool told the server it accepts.

What the Tool Does Not Show

The tool checks one address at a time, so it reports on the file you enter, usually your HTML page, and not on every CSS or JavaScript file the page loads. For those files, use your browser's Network tab or read the headers with Get HTTP Headers.

Why Compression Matters

Compression sends fewer bytes for the same page, so pages can load faster. MDN's compression guide says size reduction can reach up to 70% for some documents, which lowers bandwidth needs. Lighthouse puts it simply: text-based resources should be served with compression to minimize total network bytes.

Lighthouse flags responses that have no gzip, deflate or Brotli encoding. It skips responses under 1.4 KiB, or ones where the possible savings are under 10% of the original size, according to Chrome's audit documentation.

Search crawlers accept compression too. Google's crawlers and fetchers support gzip, deflate and Brotli, as the Google crawler overview states.

How to Use the Gzip Compression Checker

1. Open the tool and click the box that reads https://example.com.
2. Type or paste the full address of the page you want to test.
3. Click Check, or press Enter. The button reads "Checking..." while the tool shows "Fetching page and checking encoding...".
4. Read the status card. A green card names the compression in use. A red card says Compression Not Enabled. An amber card says Inconclusive and gives the HTTP status.
5. Check Bytes Transferred, Uncompressed Size and Saved by Compression below the card.
6. If compression is off, change your server or CDN settings and run the check again.

If a red error appears, such as "Failed to fetch URL", check the address and try again.

How to Turn On Compression

Turn on compression in your web server or CDN, then retest. The right step depends on your setup, so check your host's panel first.

• Nginx. The gzip directive is off by default. Add gzip on; and list more types with gzip_types. Nginx documentation notes that responses with the text/html type are always compressed once gzip is on.
• Apache. The mod_deflate module provides the DEFLATE output filter. A typical line is AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript.
• A CDN or host. Look for a compression or Brotli setting in your dashboard.

Our Nginx Config Generator can help you build the Nginx side. Apache's documentation adds that mod_deflate sends a Vary: Accept-Encoding header so that proxies do not hand compressed content to a client that cannot read it.

Best Practices for Compression

Read the HTTP Status First

If the server answers 403 or another error, it may have blocked the tool. The result then reads Inconclusive, because the error page says nothing about how your real page is served. Test a page that returns 200, or check the headers in your browser's Network tab.

Prefer Brotli, Keep Gzip as a Fallback

Lighthouse advises using Brotli when the browser supports it, because it can reduce file size more than the other algorithms. It advises gzip as the fallback, which all major browsers support.

Compress Text, Not Media

MDN recommends compression for all files except those already compressed, such as images, audio and video. Focus on HTML, CSS, JavaScript, JSON and XML.

Check the Vary Header

If you see "Not set" in the Vary Header row while your server compresses, ask your host whether caches are set up to store compressed and uncompressed copies separately. A correct Vary value protects clients that cannot read compressed responses.

Shrink the Files Too

Compression works best on lean files. Remove waste with the HTML Compressor, the CSS Minifier and the JS Minifier before you rely on the server alone.

Retest After Every Change

Server and CDN changes can take effect in different places. Run the check again after each change, then compare total weight with the Page Size Checker.

Common Use Cases

• Speed audits. Confirm compression is on before you dig into other speed problems.
• After a server move. Check that your new host or CDN compresses responses the way the old one did.
• Client reports. Show the encoding and the percentage saved for each key page.
• Plugin or config testing. Test again after you enable a caching or compression setting.
• Pre-launch checks. Test your key pages, then measure speed with the Page Speed Checker.

Related Kwebby Tools

• Get HTTP Headers shows every response header, including content-encoding and vary.
• Page Speed Checker tests how quickly a page loads.
• Page Size Checker checks total page download size.
• HTML Compressor shrinks HTML code.
• CSS Minifier and JS Minifier shrink stylesheets and scripts.
• Nginx Config Generator builds server configuration.

Final Thoughts

Compression is one of the quickest server settings to verify and fix. Run the check on your home page and your busiest landing page, and write down the encoding and the percentage saved. If either test fails, turn on compression and test again, then read the full header set with Get HTTP Headers.