GZIP/Brotli Compression Checker

The GZIP/Brotli Compression Checker is a free online tool that paste http response headers to check gzip, brotli, deflate, or zstd compression. analyze compressibility, estimated savings, and get server config guides.. It runs entirely in your browser with no installation or sign-up needed.

Detects gzip, Brotli (br), deflate, zstd, and identity from Content-Encoding. Also checks Transfer-Encoding for transport-level compression.

When Content-Length is present, uses average ratios (gzip ~70%, Brotli ~78%, deflate ~65%, zstd ~75%) to estimate original or compressed size.

Yes. All analysis runs in your browser. No data sent to any server.

Yes, the GZIP/Brotli Compression Checker is 100% free with no registration, no hidden fees, and no usage limits. All processing happens locally in your browser, ensuring complete privacy.

Yes, the GZIP/Brotli Compression Checker is fully responsive and works on smartphones and tablets. You can use it on any device with a modern web browser -- no app download required.

No account or registration is needed. Simply open the GZIP/Brotli Compression Checker in your browser and start using it immediately. There are no sign-up walls or usage restrictions.

Simply enter your input in the provided field, adjust any settings to your preference, and the tool will process it instantly. You can then copy the result to your clipboard or download it.

The GZIP/Brotli Compression Checker works in all modern browsers including Chrome, Firefox, Safari, Edge, and Opera. For the best experience, use the latest version of your preferred browser.

Gzip and Brotli are both lossless algorithms that shrink text-based responses before they travel to the browser, but Brotli is newer and more efficient. On typical text assets like HTML, CSS, and JavaScript, Brotli usually compresses 15-20% smaller than gzip, which means faster transfers and a better Largest Contentful Paint, especially on slow mobile connections. Gzip has the edge in near-universal support and slightly faster compression at lower settings, so many servers fall back to it when a client does not advertise Brotli. The browser signals which it accepts through the Accept-Encoding request header, and the server replies with Content-Encoding: gzip or br. If you paste your response headers here, the checker identifies exactly which encoding is active and nudges gzip-only sites to add Brotli.

You only need the raw response headers for a single URL, and there are three easy ways to grab them. In Chrome or Firefox DevTools, open the Network tab, reload the page, click the main document request, and copy the Response Headers block. From a terminal, curl -I https://example.com prints the headers without downloading the body, and curl -sI -H "Accept-Encoding: br,gzip" https://example.com tells the server you accept compression so it actually returns an encoded response. The tool parses any list of Header: value lines, so a plain copy-paste works fine. Pay attention to Content-Encoding, Content-Type, Content-Length, and Vary, since those drive the verdict. Paste the headers above and the checker breaks down each relevant line in plain language.

A Partial verdict means compression is technically working but something in the configuration could cause problems. The most common trigger is a missing or incomplete Vary header. If Content-Encoding shows br or gzip but there is no Vary: Accept-Encoding, a shared proxy or CDN can cache the compressed copy and later serve it to a client that never asked for it, producing garbled pages. The checker downgrades this to Partial on purpose and recommends adding the header. It also flags a Vary header that exists but omits Accept-Encoding, and transport-level oddities in Transfer-Encoding. So Partial is not a false alarm; it points to a real caching risk that a simple is-it-gzipped check would miss. Paste your headers above to see exactly which signal triggered the downgrade and how to fix it.

Compression only helps when there is redundancy left to remove, so it pays off on text-based formats and wastes effort on already-compressed binaries. Highly compressible types include HTML, CSS, JavaScript, JSON, XML, and SVG, where gzip or Brotli can cut payloads by roughly 65-78%. The checker flags these as Highly Compressible and recommends enabling encoding if it is missing. Files that are already compressed at the format level, such as JPEG, PNG, WebP, MP4, PDF, WOFF2 fonts, and ZIP archives, get almost no further reduction, so re-compressing them only burns CPU; the tool marks these Already Compressed and does not push you to encode them. Knowing the difference helps you target compression where it improves load time instead of slowing the server. Paste your headers above and the checker grades your Content-Type automatically.

The savings number is a planning estimate, not a measured value for your exact file. When a Content-Length header is present, the checker applies typical real-world ratios for text assets: about 70% reduction for gzip, 78% for Brotli, 65% for deflate, and 75% for zstd. On an already-compressed response it works backward from those ratios to approximate the original uncompressed size, and on an uncompressed response it projects how much gzip would likely save. Because actual compression depends heavily on the specific content, repetitive markup compresses far better than dense, unique text, you should treat the figure as a directional guide for prioritizing fixes rather than an exact byte count. For precise numbers, compare the real Content-Length before and after enabling compression. Paste your headers above to see the estimate alongside the full verdict.