Gzip Compression Checker
Check a public URL or pasted headers for gzip, Brotli, or identity compression with cache-variation checks and measured byte savings.| Status | Check | Evidence | Next step | Copy |
|---|---|---|---|---|
| {{ severityLabel(row.severity) }} | {{ row.check }} | {{ row.evidence }} | {{ row.next_step }} |
| Header | Value | Role | Copy |
|---|---|---|---|
| {{ row.header }} | {{ row.value }} | {{ row.role }} |
{{ recipeText }}
Text responses often contain repeated words, markup, and field names that compress well before crossing the network. HTTP content coding reduces those transfer bytes without changing the underlying media type: compressed HTML is still HTML, and compressed JSON is still JSON after the client decodes it.
Compression begins with negotiation. A client advertises acceptable codings in Accept-Encoding, possibly with preference weights. The server may answer with gzip, Brotli, Zstandard, deflate, or the uncoded identity representation. The returned Content-Encoding is the direct evidence of that choice.
| Evidence | What it establishes | What it cannot establish alone |
|---|---|---|
Content-Encoding |
Which coding was applied to this response. | How many bytes were saved. |
Vary: Accept-Encoding |
That caches should separate representations selected by the request coding preference. | Whether every cache and CDN rule is configured correctly. |
| Encoded and identity byte counts | The observed reduction for the same resource and request conditions. | End-to-end page speed or rendering time. |
Content-Type |
Whether the body is likely to benefit from compression. | Whether an origin or intermediary actually compressed it. |
HTML, CSS, JavaScript, JSON, XML, SVG, and other text-heavy formats are common candidates. JPEG, PNG, WebP, video, ZIP, PDF, and similar formats usually contain their own compression, so another HTTP coding may save little or even add overhead. Fonts sit between those cases and should be measured rather than assumed.
One successful response does not describe an entire site. Compression can vary by path, status code, method, client capabilities, content size, proxy layer, and cache state. A reliable review compares negotiated and identity responses for representative assets and treats estimated byte counts as planning clues rather than measurements.
How to Use This Tool:
Choose pasted evidence for a local review or a live probe when the public response must be measured under controlled request profiles.
- Select Paste response headers and include
Content-Encoding,Vary,Content-Type, and byte-count headers when available. For a live check, enter a neutral public URL without credentials or signed query values. - Choose a Request profile. Browser negotiation advertises modern codings, gzip fallback isolates compatibility, and identity requests the uncoded baseline. Use a custom value only when you need exact
qweights. - Set the Asset profile from the response type when
Content-Typeis absent or misleading. The profile affects suitability and clearly labeled estimates, not the observed coding header. - Use GET in live mode when body-byte comparison matters. HEAD is lighter but can omit body-derived evidence or behave differently at the origin.
- Review Compression findings before the byte chart. Confirm active coding, cache variation, MIME suitability, and whether the identity baseline is measured or estimated.
- Retest the same resource with negotiated, gzip-fallback, and identity requests before changing server or CDN rules.
Interpreting Results:
Healthy requires an active supported coding, visible Vary: Accept-Encoding, and either no byte comparison or savings at or above the selected review target. Needs review means coding is active but cache variation is missing or measured savings fall below that target. Compression missing applies when a compressible response has no active coding, while Compression usually skipped recognizes an identity response for an already compact or weak candidate.
- The savings target can be set from 20% to 90%. It is an advisory threshold, not an HTTP requirement.
- An identity value derived from an asset profile is an estimate. Prefer an actual identity request or origin byte count for decisions.
- Missing
Content-Lengthis not proof of missing compression; streaming and chunked transfers may omit it. - The transfer-time estimate covers payload bits at the chosen link rate. It excludes latency, TLS, congestion, decompression cost, caching, and rendering.
Technical Details:
Accept-Encoding lists codings a client can decode; identity means no content coding. Content-Encoding records codings applied beyond the media type’s inherent representation. When a cacheable response changes according to Accept-Encoding, the corresponding Vary field tells caches that the request header participates in representation selection.
Formula Core
Measured savings compare the encoded transfer with the uncoded representation for the same resource. Savings are rounded to two decimal places, and estimated transfer time is rounded to the nearest millisecond.
For the built-in sample, 28,640 encoded bytes versus 106,420 identity bytes saves 77,780 bytes, or 73.09%. At 10 Mbps, the byte-transfer estimate rounds to 62 ms. The calculation does not claim the page will render 62 ms sooner.
Estimation Model
When an active coding and encoded byte count are present but no identity measurement exists, the identity size is estimated from an advisory asset profile. The estimate uses encoded ÷ (1 − savings factor) and rounds to a whole byte.
| Asset profile | Gzip factor | Brotli factor |
|---|---|---|
| Auto | 64% | 72% |
| HTML | 72% | 78% |
| CSS | 74% | 82% |
| JavaScript | 68% | 76% |
| JSON | 76% | 82% |
| SVG, XML, or text | 70% | 78% |
| TTF or OTF font | 38% | 48% |
| Image, PDF, or binary | 4% | 4% |
Zstandard uses the larger of the gzip factor and three percentage points below the Brotli factor. Deflate uses the larger of 30% and eight percentage points below the gzip factor. These values support comparison when measurements are missing; they are not benchmark results for a specific file.
Rule Core
Gzip, Brotli, Zstandard, and deflate count as active codings. Identity does not. An explicit asset profile overrides MIME-based suitability, measured byte overrides replace parsed byte headers, and an identity byte count smaller than the encoded count is rejected for the savings comparison.
A live check requests negotiated, gzip-fallback, and identity variants under the selected method, timeout, and redirect policy. The final negotiated headers feed the same local analysis as pasted input, with measured identity bytes added when the baseline request succeeds.
Privacy and Accuracy Notes:
Pasted headers are analyzed in the browser. Live mode sends the public URL and selected request options to a remote checker, which then requests the target. Local and private network addresses are rejected, but public URLs can still contain sensitive paths or signed values, so use neutral targets and omit credentials.
- Compression ratios change with actual content, compression level, minimum-size rules, dynamic variation, and intermediary behavior.
- Live probes are bounded by redirect, timeout, and response-size limits; a failed or truncated check is not evidence that compression is absent.
- Retest representative HTML, API, stylesheet, script, and error responses separately because one URL cannot prove a site-wide policy.
References:
- RFC 9110: HTTP Semantics, Internet Engineering Task Force, June 2022.
- RFC 9111: HTTP Caching, Internet Engineering Task Force, June 2022.
- HTTP Content Coding Registry, Internet Assigned Numbers Authority.
- How to enable gzip compression in Apache, Simplified Guide.
- How to enable gzip compression in Nginx, Simplified Guide.