Website Gzip Checker
Test the most basic speed setting of a web server. The checker requests the page with Accept-Encoding: gzip, reads whether the response is gzip-compressed and how many bytes were transferred, compares that with the uncompressed size and Brotli, and lists the Content-Encoding of the page’s CSS and JavaScript files so you can spot assets served without compression.
- Encrypted connection
- No sign-up
- Free to use
How to use Website Gzip Checker
- Enter the page address.
- Click “Check gzip”.
- See whether gzip is on and the savings.
- Fix uncompressed assets.
Website Gzip Checker features
Real request
Accept-Encoding: gzip.
Savings
Bytes and percent.
Assets
CSS and JavaScript.
Measured, not guessed
Real transfer sizes from our server.
Safe fetching
Public addresses only, with size and time limits.
Brotli comparison
Shown alongside.
When to use Website Gzip Checker
- Checking shared hosting.
- Diagnosing slow pages.
- Server configuration reviews.
- Before a launch.
Website Gzip Checker FAQ
Why does the server choose the encoding?
Browsers say which encodings they accept; the server picks one. Checking each encoding separately shows what it supports.
Should images be compressed with gzip?
No – JPEG, PNG, WebP and video are already compressed; gzip only helps text files.
What if gzip is off?
Enable it in the server or hosting panel; on Apache use mod_deflate, on Nginx the gzip directive.
Is deflate the same?
deflate is an older, rarely used variant; gzip and Brotli are the standards.
Should I use gzip or Brotli?
Both. Serve Brotli to browsers that ask for it – it is usually smaller – and keep gzip enabled for older clients and tools that do not support Brotli.
How do I enable gzip on Apache?
Enable mod_deflate and add AddOutputFilterByType DEFLATE for text/html, text/css, application/javascript, application/json and image/svg+xml in your server or .htaccess configuration.
How do I enable gzip on nginx?
Set gzip on; and list the types with gzip_types, because nginx compresses only text/html by default.
Reading the gzip result
gzip compression has been supported by every browser for decades and usually cuts text transfer sizes by 70% or more. A server without it is leaving easy speed on the table.
Compression costs little CPU compared with the bandwidth it saves.
The checker sends one request that announces gzip support (Accept-Encoding: gzip) and reads what comes back: the Content-Encoding header and the number of bytes on the wire. Requesting the same page uncompressed and with Brotli gives the comparison, so the saving is measured, not estimated.
If the page arrives without Content-Encoding: gzip, compression is switched off for HTML. On Apache it is usually enabled with mod_deflate, on nginx with “gzip on;” plus gzip_types for CSS, JavaScript, JSON and SVG – by default nginx compresses only text/html. Images such as JPG, PNG and WebP are already compressed and should be left out.
The asset list matters as much as the page: a site often compresses its HTML but serves large JavaScript bundles uncompressed from another server or CDN. Fix those at the server that actually delivers them, then run the check again.
After enabling gzip, test both the page and the assets, because CSS, JavaScript and JSON need their content types listed separately on many servers. A Vary: Accept-Encoding header should be present so caches store compressed and uncompressed versions separately. Then compare the transferred sizes here to confirm the savings.
Very small responses of a few hundred bytes gain little from compression, so many servers skip them on purpose with a minimum length setting; that is normal and not an error.