Web

GZIP & Brotli Compression Checker

Gzip & Brotli

Compression coverage checker

Enter a URL to see which responses are compressed, how much bandwidth compression is saving, and where it's missing.

💡 Compression Testing Information

Requests the page and its key assets, inspects the Content-Encoding response header, and compares transferred size against uncompressed size for each resource.

Tool features

Comprehensive compression testing with detailed analysis and optimization recommendations
4 checks

Multi-Algorithm Testing

Test GZIP, Brotli, Deflate, and other compression algorithms

Per-Resource Analysis

Checks the page and its key assets for compression coverage

Size Comparison

Compare compressed vs uncompressed file sizes and savings

Performance Impact

Analyze bandwidth savings and performance benefits of compression

What is HTTP compression & how it works

How gzip and Brotli shrink your responses

HTTP compression shrinks text responses — HTML, CSS, JavaScript, JSON, SVG — before they're sent over the network. The server compresses the body, advertises it with a Content-Encoding header, and the browser transparently decompresses it, often cutting transfer size by 60–80% and noticeably speeding up page loads.

Two algorithms dominate: gzip, supported everywhere, and Brotli (br), which compresses text more tightly and is now broadly supported. This checker requests the page and its key assets, reads each Content-Encoding header, and compares transferred size against the uncompressed size to show exactly where compression is working — or missing.

Content-Encoding
The response header naming the algorithm used, e.g. gzip or br.
Brotli (br)
A modern algorithm that beats gzip on text; ideal for static assets.
identity
No compression applied — a compressible response sent at full size.

How to use this tool

Check a site's compression in four steps
1
Enter a URL
Type a page URL, e.g. https://example.com — the page and its key assets are tested.
2
Run the check
Click Check Compression to request each resource and read its Content-Encoding.
3
Review coverage
See the average reduction, total bytes saved, and which responses are compressed vs missing.
4
Fix the gaps
Enable gzip or Brotli for the resource types flagged uncompressed, then re-test to confirm.

Related tools

Keep debugging with tools from the same suite
3 tools
HTTP Header Checker
Analyze HTTP response headers for any website or URL with detailed header information
HTTP Status Checker
Check HTTP status codes and response details for any URL with detailed analysis
Secure Header Checker
Check security headers like CSP, HSTS, X-Frame-Options, and more with security scoring

Frequently asked questions

Common questions about HTTP compression
5 Q&A

GZIP is a widely supported algorithm that compresses text-based HTTP responses before transfer. The server sends Content-Encoding: gzip and the browser decompresses transparently, reducing transfer size and load time.

Use both. Brotli (br) compresses text more tightly than gzip and is broadly supported, so serve Brotli to clients that accept it and fall back to gzip for the rest. Most servers and CDNs can negotiate this automatically.

Text-based resources — HTML, CSS, JavaScript, JSON, XML and SVG — benefit most. Already-compressed formats like JPEG, PNG, WOFF2 and video should not be recompressed, as it wastes CPU for no gain.

Text assets typically shrink by 60–80%. The exact figure depends on the content, but enabling compression is one of the highest-impact, lowest-effort web performance wins available.

Turn on the compression module — mod_deflate/mod_brotli in Apache, gzip/brotli directives in Nginx — or simply enable it in your CDN. Then set it to compress the text MIME types your site serves and reload.