Compression detector. Gzip vs Brotli truth.
Paste raw response headers. We check Content-Encoding (gzip / brotli / deflate / zstd / none), validate the Vary: Accept-Encoding header, and recommend the right compression algorithm for your traffic profile.
Paste HTTP response headers. The detector reads Content-Encoding (gzip / br / deflate / zstd / identity), validates the Vary: Accept-Encoding header, and recommends the right compression strategy. Browser-only.
How to get headers showing compression
- curl with Accept-Encoding:
curl -I -H "Accept-Encoding: br, gzip" https://example.com(must send the request header to receive Content-Encoding back) - DevTools: F12 → Network → click the document request → Headers panel → look at Response Headers
Without Accept-Encoding in your request, most servers will serve uncompressed responses.
Sources used
- RFC 9110 §8.4 Content-Encoding — canonical HTTP semantics
- RFC 7932 Brotli compressed data format
- RFC 8878 Zstd compression specification
- MDN Content-Encoding header reference
- MDN Vary header reference
- web.dev compression guide — performance impact + setup
No data is sent to any external service. Detection happens entirely in your browser by parsing the Content-Encoding and Vary headers from your pasted text.
Privacy: parsing happens in your browser. Nothing is sent or logged.
Brotli or gzip but never neither.
HTTP compression cuts text-payload transfer size by 60-85%, with direct impact on TTFB and LCP. Brotli (Content-Encoding: br) compresses 15-25% better than gzip for HTML and CSS; modern setups ship both with content-negotiation via the Accept-Encoding request header. The detector above identifies which algorithm is in use, validates the Vary: Accept-Encoding header (a critical caching correctness check), and recommends the next move. The most common production bug it catches is missing Vary, which leads to mis-cached responses serving compressed content to clients that did not request it.
Three rules for HTTP compression. One, ship both Brotli and gzip — Brotli for clients that signal br, gzip fallback for legacy. Two, always include Vary: Accept-Encoding alongside Content-Encoding so caches know to vary the cached response. Three, do NOT compress already-compressed payloads (images, video, .gz/.br files) — wastes CPU with zero size reduction. The web.dev compression guide is the canonical setup reference.
Tools in the same cluster: CDN Detector for the edge-tier identification (most CDNs auto-handle compression). Cache Headers Checker for the broader caching audit. HTTP Headers Checker for the full headers grade.
Five answers.
What does HTTP compression do?
HTTP compression reduces transfer size of text-based responses (HTML, CSS, JS, JSON, SVG) by 60-85% before sending over the wire. The browser decompresses on receive. The savings translate directly to faster page loads, reduced bandwidth costs, and lower TTFB on slow connections. The Content-Encoding response header names the algorithm used (gzip, br for Brotli, deflate, zstd, identity for none).
Brotli vs Gzip — which is better?
Brotli (br) compresses 15-25% better than Gzip on text payloads, particularly HTML and CSS. The trade-off: Brotli is slower at the highest compression levels, so most servers use Brotli at level 4-6 (vs gzip-equivalent ratio with faster encoding). Modern setup ships both — Brotli to clients that send Accept-Encoding: br (modern browsers), Gzip fallback for legacy. The detector above flags single-encoding setups where adding Brotli is the easy win.
What about Zstd (zstandard)?
Zstd is Facebook-developed compression that hits Brotli-level ratios with significantly faster encoding speed. Browser support reached general availability in Chrome 118 (Sept 2023) and Firefox 126 (May 2024). Server support is rolling in via nginx, Apache, Cloudflare, Fastly. For high-traffic origins where compression CPU cost matters, Zstd is increasingly the right answer. For most sites, Brotli + Gzip stack remains the default.
Why is the Vary header important?
Vary: Accept-Encoding tells caches (browser cache, CDN) that the response varies based on the Accept-Encoding request header. Without Vary, a CDN might cache the gzipped response and serve it to a client that requested Brotli (or vice versa), or worse, serve a compressed response to a client that doesn't support compression. Always ship Vary: Accept-Encoding alongside Content-Encoding. The detector above flags missing Vary as a caching bug.
Does this tool save my data?
No. Header parsing happens in your browser. Nothing is sent to any server. Closing the tab clears the data. The Copy Results button puts a plain-text summary on your clipboard.
Uncompressed in production?
Our web development engagements ship Brotli + gzip with Vary correctness, audit Cache-Control + ETag for downstream caching, and deliver Core Web Vitals lift in under 2 weeks.
Published .