Gzip Compression Checker

Ignored {{ extraLinesIgnored }} extra line(s). This checker evaluates only the first non-empty URL.

Checking compression negotiation...

Check source:

Pasted headers run in this browser. Live URL mode requests browser, gzip, and identity variants through the backend.

URL target:

Example: https://example.com or https://example.com/app.js.

Response headers:

Include `Content-Encoding`, `Vary`, `Content-Type`, `Content-Length`, and any uncompressed size header when available.

Request profile:

Browser profile prefers Brotli and gzip; identity forces an uncompressed baseline.

Custom Accept-Encoding:

Use this when testing a CDN rule, crawler, or controlled client preference.

Asset profile:

Auto reads Content-Type; explicit profiles tune savings estimates and recommendations.

Savings target:

Use a higher target for large text assets and a lower target for short dynamic responses.

HTTP method:

Use GET for byte comparison; use HEAD for a lightweight header-only check.

Follow redirects:

Off inspects only the first response.

Max redirects:

Range: 0-10 hops.

Timeout:

Accepted range: 2-20 seconds.

sec

Observed compressed bytes:

Leave blank to use Content-Length or the live probe measurement.

Identity bytes:

Leave blank to estimate from asset type and observed encoding.

Transfer link:

Range: 1-1000 Mbps.

Mbps

Check	Status	Evidence	Next step	Copy
{{ row.check }}	{{ row.status }}	{{ row.evidence }}	{{ row.next_step }}

Scenario	Bytes	Savings	Interpretation	Copy
{{ row.scenario }}	{{ row.bytes }}	{{ row.savings }}	{{ row.interpretation }}

Header	Value	Role	Copy
{{ row.header }}	{{ row.value }}	{{ row.role }}

{{ requestRecipeText }}

Export to PDF Fullscreen

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

HTTP compression reduces the response bytes transferred between a server and a client. A request advertises acceptable content codings with Accept-Encoding, and the response declares the selected coding with Content-Encoding when the body was compressed.

Gzip remains the compatibility baseline for web compression, while Brotli and Zstandard can produce smaller text responses when the client and server both support them. The practical question is whether the observed response is actually encoded, whether caches can keep encoded and identity variants apart, and whether the measured byte savings are worth the CPU and configuration cost.

HTTP compression negotiation from Accept-Encoding request to encoded response, identity baseline, and Vary cache check

Text-heavy responses such as HTML, CSS, JavaScript, JSON, XML, and SVG are usually strong compression candidates. Already-compressed media, archives, many PDFs, and binary files often gain little from another content coding pass and can even waste server work.

A compression result is evidence for one observed response and one request profile. CDN rules, request method, redirect path, user agent, cache state, and content type can all change the encoding that comes back.

How to Use This Tool:

Start with pasted response headers when you already have evidence from DevTools, cURL, a CDN log, or a support ticket. Use the live URL option only for public HTTP(S) targets that are safe to send to a remote checker.

Choose Check source. Paste response headers analyzes the header block in the browser, while Live URL probe checks a public target from a remote network position.
For pasted headers, include Content-Encoding, Vary, Content-Type, Content-Length, and an original-size header such as X-Original-Content-Length when one exists. The header action hint shows how many response headers were parsed.
For a live check, enter one URL target. Missing schemes default to HTTPS, and extra pasted lines are ignored after a warning so one result set stays tied to one response.
Pick a Request profile. Browser asks for Brotli, gzip, deflate, and Zstandard; Gzip fallback only tests compatibility; Identity baseline asks for an uncompressed comparison; Custom Accept-Encoding reproduces a specific client preference.
Set Asset profile and Savings target. Auto mode reads Content-Type when available, and the target decides when the Byte savings row is marked as meeting expectations.
Open Advanced when method, redirect following, timeout, observed compressed bytes, identity bytes, or transfer link speed need to match your test case. Use GET when transferred bytes matter; HEAD can be faster but may omit compression evidence on some origins.
Read the summary and Compression Evidence first. If the live check times out, is unavailable, rejects the target, or reports only an error page, fix the setup or paste known-good headers before acting on the result.

A useful run has a visible encoding decision, a clear cache-variation row, a measured or credible identity baseline, and a savings result that matches the asset type under review.

Interpreting Results:

The summary names the main state: compressed, missing compression, skipped because the asset is not normally compressible, or ready for input. Treat that state as a triage signal, then verify the rows that explain it.

Gzip compression result cues and recommended follow-up checks
Result Cue	Best First Reading	What to Verify
Content-Encoding pass	The response declares an active content coding such as Brotli, gzip, Zstandard, or deflate.	Compare the encoded bytes with the identity baseline before assuming the setting is useful.
Cache variation fail	The response is compressed but `Vary: Accept-Encoding` is missing or not visible.	Confirm CDN and shared-cache behavior so an encoded variant is not reused for the wrong client.
Byte savings below target	Compression exists, but the measured or estimated reduction is smaller than the selected threshold.	Check whether the response is tiny, already compressed, dynamically generated, or using a weak compression rule.
MIME suitability info	The content type looks like media, archive, PDF, or binary data where another content coding may add little value.	Focus compression work on text assets and keep media optimization separate.
HTTP status warning	The compression evidence may describe an error page instead of the intended asset.	Retest the route that users actually fetch, with the same redirect and method choices.

False confidence is common with compression checks. A Content-Encoding: gzip header proves that a coding was applied, not that the response became much smaller, not that every CDN edge serves the same variant, and not that all file types should be compressed.

Use Savings Scenario to compare observed, identity, gzip estimate, and Brotli estimate rows. Use Header Ledger when the evidence needs to be copied into a ticket, and use Request Recipe to reproduce the same request profile outside the page.

Technical Details:

HTTP content coding is representation metadata. The body can be stored and transmitted in a coded form while keeping the same underlying media type, then decoded by the final recipient before rendering or use. Content-Length normally describes the encoded representation, not the original uncoded size, unless a separate header or measurement provides that baseline.

Accept-Encoding is the negotiation input. It can list codings such as br, gzip, deflate, zstd, identity, and wildcard values, optionally weighted with quality values. identity means no content coding. Asking for identity is useful for byte comparison, but an origin or intermediary may still behave differently by method, route, cache, or user agent.

Rule Core:

Compression evidence rules used to classify a response
Check	Pass or Warning Condition	Why It Matters
Content coding	`br`, `gzip`, `x-gzip`, `zstd`, or `deflate` counts as active compression; `identity` or no header counts as an unencoded response.	The declared coding is the first proof that the server selected a compressed representation.
Cache variation	When compression is active, `Vary` should include `Accept-Encoding`.	Shared caches need separate entries for clients that accept different encodings.
MIME suitability	Text, JSON, JavaScript, XML, SVG, CSS, and suitable font responses are treated as compressible; common image, audio, video, archive, gzip, and PDF responses are treated as poor candidates.	Compression should target data that has redundant text or structure, not bytes already packed by a specialized format.
Byte savings	Observed or estimated savings must be greater than or equal to the selected target to be marked as met.	A present header is not enough when the encoded response is almost the same size as the baseline.
Negotiation sanity	If an identity request still receives active compression, the result is marked for review.	A proxy, CDN rule, or origin setting may be rewriting the request or ignoring the requested coding preference.

Formula Core:

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

savings = \frac{identity_bytes - encoded_bytes}{identity_bytes} \times 100

If Content-Length reports 28,640 encoded bytes and an identity measurement reports 106,420 bytes, the calculation is (106420 - 28640) / 106420 x 100, which rounds to 73% savings. With a 60% Savings target, the Byte savings row is marked as met.

When an identity baseline is not measured, the estimate uses the selected asset profile and observed coding. Text and structured payload profiles assume higher reductions than fonts, and binary media profiles assume little or no reduction. An estimate is useful for triage, but a direct identity request or reliable original-size header is stronger evidence.

transfer_ms = \frac{bytes \times 8 \times 1000}{link_mbps \times 1000000}

The transfer-time estimate uses the Transfer link value only for the scenario table. It is a byte-transfer comparison, not a full page-load prediction, because compression CPU time, TLS setup, congestion, cache hit rate, and browser scheduling are outside that simple estimate.

Input and Evidence Map:

Inputs and evidence sources used in compression analysis
Evidence	Preferred Source	Fallback Source
Encoded size	Observed compressed bytes or live transferred bytes.	`Content-Length` or encoded-size headers when available.
Identity size	Identity bytes or a live identity request.	Original-size headers such as `X-Original-Content-Length`, then an asset-profile estimate.
Compressibility	Asset profile when explicitly selected.	`Content-Type` patterns when the profile is set to auto.
Cache safety	`Vary: Accept-Encoding` on compressed responses.	Manual CDN or proxy review when the header is absent or hidden.

Privacy and Accuracy Notes:

Pasted-header mode works in the browser from the text you provide. Live URL mode must send the public target URL and selected request options to a remote checker so it can request headers and byte counts that a normal browser page cannot reliably inspect across origins.

Check only public URLs you are authorized to test.
Do not use signed links, one-time login links, password-reset URLs, bearer tokens, private query strings, or private intranet hosts.
Live checks can differ from your own browser because network location, CDN edge, cache state, redirect following, method, and user agent can change the response.
Remote checks reject local and private-network targets; paste response headers instead when reviewing internal systems.

Worked Examples:

HTML page 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 summary reports gzip active, Content-Encoding passes, Cache variation passes, and Byte savings shows about 73% saved. That is strong evidence that compression is working for this text response.

Compressed response missing Vary

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 fix is not more compression. The first follow-up is cache configuration so shared caches keep Brotli, gzip, and identity variants separate.

Binary asset with no coding

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

Live check times out

A live run against a slow route reports that the probe timed out. Increase Timeout only if 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:

Does gzip active mean the page is optimized?

No. Content-Encoding shows that a coding was applied, but Byte savings, MIME suitability, status, cache behavior, and asset choice decide whether the result is useful.

Why does the tool care about Vary?

A compressed response that varies by Accept-Encoding should say so with Vary: Accept-Encoding. Without that cache signal, a shared cache can store one variant and serve it to a client that asked for a different encoding.

Why is the identity baseline sometimes estimated?

Pasted headers often include only the encoded Content-Length. Add Identity bytes, paste an original-size header, or use an identity request when you need measured savings instead of an asset-profile estimate.

Why did a live check differ from my browser?

The remote checker has its own network position and request profile. CDN edge, cache state, method, redirect handling, and Accept-Encoding value can all change the returned compression headers.

Can I check an internal service?

Use pasted-header mode for internal systems. Live URL mode is for public HTTP(S) targets and rejects local or private-network addresses.

What should I do when the live probe is unavailable?

Paste a response header block from DevTools, cURL, a CDN log, or a support ticket. The local header path still checks Content-Encoding, Vary, MIME suitability, and byte-savings evidence.

Glossary:

Accept-Encoding: The request header that lists content codings the client can accept, such as gzip, Brotli, 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 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 the compatibility fallback.

References:

RFC 9110: HTTP Semantics, Internet Engineering Task Force, June 2022.
Hypertext Transfer Protocol (HTTP) Parameters, Internet Assigned Numbers Authority.
RFC 1952: GZIP File Format Specification Version 4.3, RFC Editor, May 1996.
Accept-Encoding header - HTTP, MDN Web Docs, July 4, 2025.
Content-Encoding header - HTTP, MDN Web Docs, July 4, 2025.
HTTP caching, MDN Web Docs, May 4, 2026.