{{ summaryTitle }} {{ summaryValue }} {{ summaryLine }} {{ badge.label }}{{ badge.value }}
Compression evidence source and review controls
Pasted headers stay in this browser. Live URL mode sends one public target and the selected request options to the remote checker.
Include Content-Encoding, Vary, Content-Type, Content-Length, and an original-size header when available.
{{ sourceMeta }}
{{ sourceActionHint }}
Use a neutral public target such as https://example.com/. Missing protocol defaults to HTTPS.

{{ liveProbeStatus }}

Browser covers modern content codings; gzip fallback and identity isolate compatibility and baseline behavior.
Example: br;q=1, gzip;q=0.8, identity;q=0.1.
Choose an explicit type when Content-Type is absent or misleading.
Use 20–90%. The default 60% is an advisory review target, not an HTTP requirement.
{{ params.savings_target }}%

{{ workflowFeedback }}

{{ handoffStatus }}
Use GET when byte comparison matters.
Turn off to inspect only the first response.
{{ params.follow_redirects ? 'On' : 'Off' }}
Use 0–10 hops.
Use 2–20 seconds.
seconds
Keep 0 to use observed or parsed evidence.
bytes
Keep 0 to use an original-size header or a clearly labeled profile estimate.
bytes
Use 1–1,000 Mbps.
Mbps
StatusCheckEvidenceNext stepCopy
{{ severityLabel(row.severity) }}{{ row.check }}{{ row.evidence }}{{ row.next_step }}
HeaderValueRoleCopy
{{ 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 needed to judge HTTP compression
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.

  1. 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.
  2. 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 q weights.
  3. Set the Asset profile from the response type when Content-Type is absent or misleading. The profile affects suitability and clearly labeled estimates, not the observed coding header.
  4. 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.
  5. Review Compression findings before the byte chart. Confirm active coding, cache variation, MIME suitability, and whether the identity baseline is measured or estimated.
  6. 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-Length is 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.

S%= BidentityBencodedBidentity ×100
Tsaved= Bsaved×8×1000LMbps×1000000

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.

Advisory savings factors used for identity and encoded byte estimates
Asset profile Gzip factor Brotli factor
Auto64%72%
HTML72%78%
CSS74%82%
JavaScript68%76%
JSON76%82%
SVG, XML, or text70%78%
TTF or OTF font38%48%
Image, PDF, or binary4%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: