Gzip Compression Checker

Introduction

HTTP compression is a representation choice: the server keeps the same resource, but sends a coded version of the response body so fewer bytes cross the network. A browser, crawler, API client, or command-line request first advertises which content codings it can decode. The server then chooses a coding such as gzip, Brotli, or Zstandard, or sends the identity form when compression is unavailable or unsuitable.

The distinction between media type and content coding prevents a common misunderstanding. An HTML document remains HTML after compression, and a JSON API response remains JSON; the coding only changes how the bytes are carried. That is different from file-format compression, where a PNG, WebP, ZIP archive, video stream, or PDF may already store its own compact representation before HTTP sees it.

Several headers have to agree before a compression read is trustworthy. Accept-Encoding names the request preference, Content-Encoding names the coding actually applied, and Content-Length usually describes the encoded representation rather than the uncompressed body. Vary matters whenever shared caches are involved, because gzip, Brotli, Zstandard, and identity variants should not be reused for clients that asked for different encodings.

Compression value depends heavily on the response type. HTML, CSS, JavaScript, JSON, XML, SVG, and other structured text often shrink well because tags, keys, selectors, whitespace, and repeated words create redundancy. Already-compressed images, audio, video, archives, and many PDFs usually gain little and may even become larger after another coding layer adds overhead.

A compression reading is always tied to one request shape. URL path, redirect handling, method, cache state, CDN edge, user agent, server load, and the requested Accept-Encoding value can all change the observed headers and byte counts. Strong troubleshooting separates three questions: whether a coding was selected, whether the response was a good compression candidate, and whether the measured savings justify the server or CDN behavior.

How to Use This Tool:

Start from the evidence you actually have. Pasted headers are best for DevTools captures, cURL output, CDN logs, and support tickets; live URL checks are for public HTTP(S) targets that need fresh negotiation and byte comparison.

1. Choose Check source. Paste response headers analyzes the header block in your browser, while Live URL probe sends one public target and request options to the remote checker.
   Use pasted headers for internal systems, signed links, authenticated URLs, or anything that should not be requested from a remote network location.
2. Paste the response evidence or enter one URL target. Include Content-Encoding, Vary, Content-Type, Content-Length, and an original-size header when one is available.
3. Select the Request profile. Browser mode advertises Brotli, gzip, deflate, and Zstandard; gzip fallback tests compatibility; identity asks for an uncompressed baseline; custom mode reproduces a specific client preference.
4. Set Asset profile and Savings target. Auto mode reads the visible content type when possible, while explicit profiles keep the estimate aligned with HTML, CSS, JavaScript, JSON, SVG, font, or binary responses.
5. Open Advanced when the method, redirect handling, timeout, observed compressed bytes, identity bytes, or transfer link speed must match a real test case.
   Use GET when transferred byte counts matter. HEAD is lighter, but some origins omit compression details or body-derived sizes on header-only responses.
6. Check the summary and Compression Evidence rows first. A reliable first pass has a clear encoding decision, MIME suitability, cache variation status, and either measured byte savings or a plainly labeled estimate.
7. Use the follow-up tab that matches the job: Savings Scenario for variant comparison, Compression Byte Comparison for byte charts, Header Ledger for parsed evidence, Request Recipe for reproducible cURL commands, and JSON for a structured copy of the run.

Interpreting Results:

The summary gives a triage state such as compression active, compression missing, compression usually skipped, or ready for evidence. Do not stop at the summary badge. The rows below it explain whether the response is encoded, whether the asset type is a good candidate, whether shared caches have the right variation signal, and whether the byte savings meet the chosen target.

Content-Encoding: gzip proves that a coding was declared for that response. It does not prove that the uncoded response was much larger, that every CDN edge behaves the same way, or that compression should be applied to every asset. The strongest evidence pairs the encoding header with a measured identity baseline, not only an estimated one.

Use the request recipe when you need to reproduce the result in a terminal or share a support case. Keep the same URL, method, redirect choice, and Accept-Encoding value, then compare the returned headers and byte counts with the evidence rows.

Technical Details:

HTTP content coding is representation metadata. A representation can be encoded for transfer while retaining the same media type, then decoded by the recipient before display or parsing. Because Content-Length describes the bytes sent for the selected representation, it often describes the compressed size, not the original identity size.

Accept-Encoding is the negotiation input. It can name codings such as br, gzip, deflate, zstd, identity, and *, with optional quality weights. identity means no content coding. A server can still choose identity when it is acceptable, especially for already-compressed files, small responses, or periods when compression cost is not worth the byte reduction.

Rule Core:

Formula Core:

The main savings percentage compares encoded bytes with an identity baseline for the same response. The displayed percentage is rounded to a whole number.

For example, 28,640 encoded bytes compared with a 106,420 byte identity baseline gives (106420 - 28640) / 106420 x 100, which rounds to 73% savings. If the target is 60%, that response meets the byte-savings threshold.

When no measured identity baseline is available, the estimate uses the selected asset profile and observed coding. Text and structured payload profiles assume stronger reductions than font or binary profiles. Estimates are useful for triage, but a direct identity request or a reliable original-size header is better evidence for a support ticket or production change.

The transfer-time comparison is only a byte-transfer estimate at the selected link speed. It does not model compression CPU cost, TLS setup, congestion, cache hit rate, browser scheduling, render blocking, or the rest of a page-load waterfall.

Evidence Map:

Privacy and Accuracy Notes:

Pasted-header mode analyzes the text you provide in your browser. Live URL mode must send the public target URL and selected request options to a remote checker so it can make cross-origin requests and measure response bytes that a browser page cannot reliably inspect by itself.

• Check only public URLs you are authorized to test.
• Do not submit signed links, password-reset links, bearer tokens, private query strings, one-time URLs, or internal hostnames.
• Live checks reject local and private-network targets; paste headers instead when reviewing internal systems.
• Live results can differ from your browser because network location, CDN edge, cache state, method, redirect handling, and user agent can all affect the returned headers.
• Header-only responses can omit details that appear on a full GET response, so use GET when byte comparison matters.

Worked Examples:

HTML response with useful gzip

A pasted header block contains Content-Type: text/html, Content-Encoding: gzip, Content-Length: 28640, X-Original-Content-Length: 106420, and Vary: Accept-Encoding. The evidence rows pass content coding and cache variation, while byte savings round to 73%. That is strong evidence that compression is active and useful for this text response.

Brotli response missing cache variation

A CSS asset returns Content-Encoding: br and a good size reduction, but the cache variation row fails because Vary is missing or does not include Accept-Encoding. The follow-up is cache configuration, not a different compression algorithm. Shared caches need to separate Brotli, gzip, and identity variants.

Binary asset with no coding

A PNG image returns Content-Type: image/png, a normal Content-Length, and no Content-Encoding. The result can show that compression is usually skipped, and MIME suitability is informational rather than a failure. Optimize the image itself instead of wrapping already-compressed bytes in gzip.

Live probe times out

A live run against a slow route reports a timeout. Increase Timeout only when the public target is correct and expected to respond slowly. Otherwise paste headers from cURL or DevTools, or retest a smaller static asset where compression behavior is easier to isolate.

FAQ:

Glossary:

Accept-Encoding

The request header that lists content codings the client can accept, such as Brotli, gzip, deflate, Zstandard, or identity.

Content-Encoding

The response header that names the coding applied to the response body.

Content coding

A lossless representation transform used by HTTP so a response can be compressed while keeping its media type.

Identity

The no-compression coding used as a baseline for comparing encoded and unencoded byte counts.

Vary

The response header that tells caches which request headers influenced the response and must match before a stored response can be reused.

Brotli

A modern HTTP content coding often used for text-heavy assets when the client and server both support it.

Gzip

A widely supported content coding based on the gzip format and commonly used as a compatibility fallback.

Zstandard

A newer content coding identified as zstd in HTTP headers when the client and server both support it.

References:

• RFC 9110: HTTP Semantics, Internet Engineering Task Force, June 2022.
• HTTP Content Coding Registry, Internet Assigned Numbers Authority.
• Compression in HTTP, MDN Web Docs.
• Accept-Encoding header, MDN Web Docs.
• Content-Encoding header, MDN Web Docs.
• Vary header, MDN Web Docs.
• How to enable gzip compression in Apache, simplified.guide.
• How to enable gzip compression in Nginx, simplified.guide.
• How to use compression when downloading with cURL, simplified.guide.
• How to show HTTP response headers with cURL, simplified.guide.