---
title: Is my site compressed? How to test it with the Gzip Compression Test
description: PageSpeed Insights tells you to enable text compression, and you're sure gzip is already on. To test gzip compression, request the page with Accept-Encoding: gzip and check for Content-Encoding: gzip in the response, then compare the bytes with and without it. Here's how with the free Gzip Compression Test, how to read its Brotli-first answer, and the curl commands that measure the saving.
canonical: https://watchfor.io/blog/how-to-test-gzip-compression
---

# Is my site compressed? How to test it with the Gzip Compression Test

2026-10-04 · WatchFor Team · Guides · guides, performance, http

PageSpeed Insights tells you to enable text compression, and you're sure gzip is already on. To test gzip compression, request the page with Accept-Encoding: gzip and check for Content-Encoding: gzip in the response, then compare the bytes with and without it. Here's how with the free Gzip Compression Test, how to read its Brotli-first answer, and the curl commands that measure the saving.

To test whether a site uses gzip compression, request a page with the
header `Accept-Encoding: gzip` and look for `Content-Encoding: gzip` in the
response. If the header is there, the server compressed the body. If it's
missing, the page traveled uncompressed. To see the saving, download the
page once with compression and once without and compare the byte counts.

The free [Gzip Compression Test](/gzip-test) checks a site's compression
from a WatchFor probe location. It asks for Brotli, the newer format, and
shows exactly which `Content-Encoding` came back; the curl commands below
cover the gzip fallback and the sizes. No signup.

## What this tool answers

*Does this site compress its pages, and with what?* Reach for it when
PageSpeed Insights or Lighthouse flags "Enable text compression", after
moving to a new server or CDN, after changing nginx or Apache config, or
when pages feel heavy on slow connections. Text compression usually cuts
HTML, CSS and JavaScript to a fraction of their size, and it's a
configuration change, not a code change.

## A real example

### Testing gzip compression when PageSpeed says it's off

The situation: a report says text compression is missing, the team says
gzip has been on for years, and nobody is sure who's right. We tested a
large public site, `www.wikipedia.org`, with the
[Gzip Compression Test](/gzip-test):

![The Gzip Compression Test result for www.wikipedia.org from Vilnius: Brotli No, an amber Not supported badge, Encoding shown as a dash, check time 106 ms](/blog/how-to-test-gzip-compression-result.webp)

**Brotli: No, encoding: none.** That reads alarming at first, but the test
offers *only* Brotli (`Accept-Encoding: br`), and a server that doesn't
speak Brotli is allowed to answer uncompressed. So this result tells us
Wikipedia doesn't serve Brotli on that page. It doesn't yet say whether
gzip is on.

So we asked for gzip, from our own machine:

| Request | `Content-Encoding` | Bytes transferred |
| --- | --- | --- |
| `Accept-Encoding: br` | none | 93,955 |
| `Accept-Encoding: gzip` | gzip | 22,767 |
| no compression (`identity`) | none | 93,955 |

**The answer:** gzip is on and works. It shrinks the home page from 93,955
to 22,767 bytes, about 76% smaller. Brotli isn't offered, so browsers that
prefer Brotli still get gzip. If a report on your own site says compression
is missing while a check like this shows gzip, look at *which* request it
flags: usually a stylesheet, a script or a JSON response whose content
type isn't in the server's compression list, rather than the page itself.

## How to read the results

| What you see | What it means |
| --- | --- |
| **Brotli · Yes** | The response came back with `Content-Encoding: br`. The site compresses, with the better format. |
| **Brotli · No, Encoding `gzip`** | The server ignored the Brotli offer and used gzip. Compressed, just not with Brotli. |
| **Brotli · No, Encoding —** | No `Content-Encoding` header: the body came back uncompressed *to a Brotli-only request*. Run the gzip curl below before concluding the site doesn't compress at all. |
| **Badge colour** | Green for Brotli, amber otherwise. Amber is a suggestion, not a failure. |
| **Domain** | The site's home page is fetched over HTTPS, following up to 10 redirects. Paths aren't tested. |
| **Check time** | How long the probe waited for the response headers. It isn't a measure of page size. |

## More ways to use it

- **After a server move.** New hosting often ships without compression on
  for every content type. Test the old and new setups with the same curl
  loop.
- **When a CDN sits in front.** The CDN compresses for visitors even when
  your origin doesn't. Test the public URL and the origin separately to
  know which one does the work.
- **Checking API responses.** JSON compresses as well as HTML. Point the
  curl commands at an API URL to see whether it's compressed.
- **Before adding Brotli.** Measure gzip first, then compare after
  enabling Brotli; [Brotli checker guide](/blog/how-to-check-brotli-compression)
  covers that step.

## Tips and gotchas

- **Compression is negotiated.** The client lists what it accepts in
  `Accept-Encoding`, and the server picks one or none. A test that offers
  one format only can see "none" from a server that handles the others
  fine.
- **Compress text, not media.** HTML, CSS, JavaScript, JSON, SVG and XML
  benefit. JPEG, PNG, WebP, video and WOFF2 fonts are already compressed,
  and gzipping them wastes CPU.
- **nginx compresses only `text/html` by default.** Turning on `gzip on;`
  without `gzip_types` leaves CSS, JavaScript and JSON uncompressed, a
  common cause of the PageSpeed warning:

```nginx
gzip on;
gzip_vary on;
gzip_min_length 1024;
gzip_types text/css application/javascript application/json image/svg+xml text/plain;
```

- **`gzip_vary on` adds `Vary: Accept-Encoding`,** so shared caches keep a
  compressed and an uncompressed copy apart.
- **Tiny responses don't need it.** Under a kilobyte, the gzip header and
  the CPU time outweigh the saving, which is why `gzip_min_length` exists.
- **More background:** [gzip vs Brotli](/blog/gzip-vs-brotli) compares the
  two formats, and [how to speed up your website](/blog/how-to-speed-up-your-website)
  puts compression in context with images and caching.

## Check it from the command line too

Ask for gzip and print the encoding the server picked:

```bash
curl -s -o /dev/null -D - -H 'Accept-Encoding: gzip' https://www.wikipedia.org/ \
  | grep -iE '^(content-type|content-encoding)'
```

```text
content-type: text/html
content-encoding: gzip
```

Compare the bytes on the wire with and without compression. curl doesn't
decompress unless you pass `--compressed`, so `size_download` is what
actually traveled:

```bash
for e in identity gzip br; do
  printf '%s: ' "$e"
  curl -s -o /dev/null -H "Accept-Encoding: $e" -w '%{size_download} bytes\n' https://www.wikipedia.org/
done
```

```text
identity: 93955 bytes
gzip: 22767 bytes
br: 93955 bytes
```

The `br` line matches the tool: offered only Brotli, the server sent the
full 93,955 bytes. To check a single asset, replace the URL with the
stylesheet or script that PageSpeed flagged.

## Keep watching it

Compression tends to disappear in migrations and config rewrites, and
nobody notices until a performance report flags it weeks later. A
[compression monitor](/compression-monitoring) repeats the Brotli request on
a schedule and warns through its **Brotli Not Supported** rule when the
response stops coming back as `br`. For a site that serves only gzip, like
the one above, that rule would warn from the start, so it's the right
monitor once you've turned Brotli on.

## FAQ

**How do I check if gzip compression is enabled?**
Run `curl -sI -H 'Accept-Encoding: gzip' https://yoursite/` and look for
`content-encoding: gzip`, or open DevTools, select the request in the
Network tab and check its response headers.

**Why does PageSpeed say enable text compression when gzip is on?**
The warning lists specific requests. Usually those are assets whose content
type isn't in the server's compression list (nginx's `gzip_types`), or
files served from another host such as a CDN or third-party script.

**Should I use gzip or Brotli?**
Both: serve Brotli to clients that accept it and keep gzip as the fallback.
Browsers offer both over HTTPS, and the server picks the best one it
supports.

---

Canonical page: https://watchfor.io/blog/how-to-test-gzip-compression · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt