PeopleAreGeek
FR

Compression Checker

Paste a URL and see what Gzip or Brotli is really doing on it: HEAD next to GET headers, Vary, cache and the redirect trail, all on one screen.

This compression checker shows you what Gzip or Brotli is really doing on a URL, server-side, instead of flashing a green or red badge and leaving you to guess. Paste a public address and it reads the exact first HEAD response, grabs the GET page headers right beside it when the backend can parse the destination as HTML, walks the redirect trail, then pulls out Content-Encoding and Vary and parks the cache headers next to all of it. Why bother? Because a bare no-compression badge lies half the time. A redirect quietly swapped the real page out, or HEAD answered one way while the browser GET would answer another, or you pointed it at a JPEG that was already packed. It scores the run, names the text resources worth chasing versus the media you should leave alone, and hands you a copyable report. Built for the WordPress, CDN, reverse proxy and origin audit you run when one page feels heavier than it should.

Queries run through the PeopleAreGeek lookup service. We log nothing.

HTTP compression and delivery signal audit

Paste a public URL. I'll show you what's actually going on with Gzip or Brotli on it. First HEAD headers, the GET page headers right beside them, the redirect trail, the cache context, all on one screen. Why bother? Because a bare "no compression" badge lies, and it lies a lot. Half the time you're staring at a redirect that swapped the page out, or an image nobody ever meant to gzip. I got tired of squinting at a red dot and guessing which one it was.

Compression is negotiated per response, not per site. So I sample it carefully. The first header read hits the exact URL you typed, before anything chases a redirect. The GET page read only shows up when the backend can read the destination as HTML.

What a compression checker should prove

A compression checker should prove what Gzip or Brotli is really doing on a URL, not flash a green or red badge and call it a day. Compression is one of those wins nobody brags about. It's free, though, and it's real. Send HTML, CSS, JavaScript, JSON, XML or SVG over the wire with Gzip or Brotli negotiated properly and the transfer drops hard. Honestly, all I ever wanted from a checker was honesty. Show me the negotiation. Don't scream "broken" the second a Content-Encoding header goes missing, because most of the time nothing's broken. A redirect quietly swapped the real page out. Or HEAD answered one way and the browser's GET would have answered another. Or, look, you pointed it at a JPEG that was already packed, and a second layer of compression buys you basically nothing. So this one keeps the context right there in the report instead of tossing it. It reads the exact first response, grabs the GET page headers when the backend can read the destination as HTML, walks the redirect rows, pulls out Content-Encoding and Vary, then parks the cache headers next to all of it.

Gzip, Brotli and the response that matters

Gzip is everywhere and it isn't going anywhere. Brotli turns up a lot for modern text, mostly over HTTPS. Honestly though, I'd stop chasing the shinier name. What actually matters is whether the final text your visitors download lands small and gets cached right for each variant you serve. And keep this in mind: the server can hand Brotli to one client, Gzip to the next, a plain uncompressed body to some diagnostic tool that sent odd headers. The one response you happened to sample isn't the whole story.

  • Content-Encoding names the encoding applied to that one response I sampled. Nothing more.
  • Vary is what tells caches to keep the Accept-Encoding variants apart so they don't cross the streams.
  • Content-Type is how you decide whether compression even belongs on this resource at all.
  • Cache-Control covers a chunk of what happens on repeat visits, and at the CDN too.
  • Redirect path is your proof you audited the real destination, not some stale URL.

When missing compression deserves action

So when would I actually chase this down? You've got a real HTML page, a stylesheet, a script, a JSON response or an XML feed big enough to feel, and no compression turns up anywhere on the path that matters. That one's worth your time. Go poke at the origin and the edge. On WordPress it's usually one of a small cast of suspects: a hosting default, an Nginx or Apache rule, a performance plugin, a CDN toggle, a proxy rule, a cache layer quietly handing back a different variant than the one you think you're getting. What I would not do is start gzipping your JPEGs, WebP, MP4s or ZIPs just to flip a checker green. They're already compressed. You'll burn CPU for nothing. And be honest about size while you're at it. Compression shaves bytes off text, full stop. It won't rescue a 4 MB hero image, a pile of scripts, render-blocking work, a cache you never bothered to set up, or a backend that needs a whole second to build the page.

A practical compression workflow

  1. Test the canonical final URL. Not the old one that just bounces you somewhere else.
  2. Read Content-Type first, so you already know whether compression even belongs here.
  3. Line up Content-Encoding and Vary across whatever samples you actually managed to get.
  4. Look at the cache headers and CDN behavior before you go rewriting server rules blind.
  5. Retest after every change: a cache purge, a hosting tweak, a CDN flip, a plugin toggle.

Frequently asked questions

Is Brotli always better than Gzip?

Always? No. Brotli usually squeezes text harder, sure, but the encoding that actually wins is the one negotiated right and served every time without flaking. The one proven on your real path. Gzip still pulls its weight and runs everywhere, so don't write it off.

Should every file be compressed?

Nope. Text is the target here. Your images, videos, archives and modern fonts already come compressed or packed some other way, so bolting Gzip on top mostly burns CPU to save a rounding error.

Does compression guarantee a fast page?

I wish. All it does is cut the transfer cost on the stuff worth compressing. Backend latency, caching, render work, your JavaScript, image weight, every third-party script, they all still get a vote. And they usually shout louder than compression ever will.

Why is my compression not working?

Round up the usual suspects. The server module isn't switched on. Your content type isn't in the compressible list. The response is already binary. Or some proxy in the middle is quietly stripping the Accept-Encoding header before it ever reaches the origin.