Brotli & Gzip Compression Inspector
Test exactly how many bytes are saved when compressing specific text blocks using the native CompressionStream API. Compare Brotli and Gzip savings side by side.
Brotli & Gzip Compression Inspector
Paste text to compare Brotli and Gzip compression sizes β uses the native browser CompressionStream API.
How to use the Brotli & Gzip Compression Inspector
Paste any text, HTML, CSS, JavaScript, or JSON into the text area and click Inspect Compression. The tool compresses your input using both Gzip and Brotli via the browser's native CompressionStream API, then shows the compressed byte sizes and savings percentages side by side. A winner row at the bottom shows which algorithm saves more and by how many bytes.
Paste your actual HTML output from a CMS page (typically 15-50 KB) to see whether Brotli's 15-25% advantage over Gzip justifies the extra CPU cost on your server. If your server is CPU-constrained, Gzip at level 6 might be more practical than Brotli at level 11.
Test your CSS framework output (Tailwind, Bootstrap) and JavaScript bundles separately. A 200 KB CSS file might compress to 35 KB with Brotli (82.5% reduction) while a 500 KB JS bundle compresses to 120 KB (76% reduction). This tells you which assets to prioritise for pre-compression on the server.
Paste a sample JSON API response to measure compression savings. A typical 10 KB JSON payload compresses to about 2 KB with Gzip and 1.8 KB with Brotli. For APIs serving millions of requests per day, that 200-byte difference per request adds up to significant bandwidth savings over a month.
Compression algorithms and measurement
The tool uses the native CompressionStream API available in modern browsers to perform real compression without sending your data to any server. Input text is first converted to bytes using TextEncoder, then piped through the compression stream, and the resulting byte length is measured.
Gzip (DEFLATE + wrapper)
Gzip wraps the DEFLATE algorithm (LZ77 sliding window + Huffman coding) with a 10-byte header and 8-byte checksum trailer. LZ77 finds repeated byte sequences within a 32 KB sliding window and replaces duplicates with back-references. Huffman coding then assigns shorter bit codes to more frequent symbols. Typical compression ratio on HTML is 60-80%.
Brotli (LZ77 + Huffman + static dictionary)
Brotli uses a similar LZ77 + Huffman approach but adds a pre-computed static dictionary of 120 KB containing common HTML, CSS, and JavaScript patterns. This dictionary gives Brotli a head start on web content -- it already knows what "function", "return", "margin:", and common HTML tags look like. The result is 15-25% smaller files than Gzip on typical web assets.
Measurement pipeline
The pipeline converts input to UTF-8 bytes via TextEncoder, creates a CompressionStream, writes the bytes through the writable side, reads compressed chunks from the readable side, and sums their byteLength values. The savings percentage is calculated as 1 minus compressed size divided by original size, multiplied by 100.
Frequently asked questions
Why is Brotli usually smaller than Gzip?
Brotli includes a 120 KB static dictionary of common web content patterns -- HTML tags, CSS properties, JavaScript keywords. When Brotli sees "</div>" or "function(" in your input, it can reference the dictionary entry instead of encoding it from scratch. Gzip has no such dictionary and must learn all patterns from your input alone. The tradeoff is that Brotli compression is 20-50% slower than Gzip at equivalent compression levels.
Does my browser support the CompressionStream API?
Supported in Chrome 80+ (February 2020), Edge 80+, Firefox 113+ (May 2023), and Safari 16.4+ (March 2023). If your browser does not support it, the tool displays an error message suggesting Chrome or Firefox. The API performs compression natively in the browser -- no server is involved.
How much compression benefit can I expect?
Typical savings: HTML 60-80% reduction (highly repetitive with repeated tags), CSS 65-80% (repetitive property names and values), JavaScript 60-75% (variable names compress well), JSON 70-90% (key names repeat across objects). Binary content like images and fonts compress poorly because they lack repetitive byte patterns.
Does minifying before compressing make a difference?
Yes, significantly. Minification removes comments, whitespace, and shortens variable names, creating more repetitive byte patterns. A 300 KB unminified CSS file might compress to 45 KB with Gzip (85% reduction), while the same file minified to 200 KB compresses to 28 KB (86% reduction). The absolute savings are larger on the unminified file, but the minified + compressed combination gives the smallest final size.
Should I enable both Gzip and Brotli on my server?
Yes. Configure your server to serve Brotli to browsers that support it (Accept-Encoding: br) and fall back to Gzip for older browsers. Nginx supports this natively with the brotli and gzip directives. Cloudflare, AWS CloudFront, and most CDNs handle this automatically. About 96% of global browsers support Brotli as of 2024.