---
title: Is my site serving Brotli? How to check with the Brotli Checker
description: You switched Brotli on in nginx or at your CDN, and now you want proof that visitors actually get it. To check Brotli compression, request the page with Accept-Encoding: br and read the Content-Encoding header that comes back. Here's how to do it in seconds with the free Brotli Checker, why a "No" doesn't mean your site is uncompressed, and the curl commands that measure the bytes.
canonical: https://watchfor.io/blog/how-to-check-brotli-compression
---

# Is my site serving Brotli? How to check with the Brotli Checker

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

You switched Brotli on in nginx or at your CDN, and now you want proof that visitors actually get it. To check Brotli compression, request the page with Accept-Encoding: br and read the Content-Encoding header that comes back. Here's how to do it in seconds with the free Brotli Checker, why a "No" doesn't mean your site is uncompressed, and the curl commands that measure the bytes.

To check whether a site serves Brotli, request a page with the header
`Accept-Encoding: br` and look at the `Content-Encoding` header in the
response. `br` means the server compressed the body with Brotli. Anything
else, or no header at all, means it didn't, and browsers that ask for Brotli
get gzip or the raw bytes instead.

The free [Brotli Checker](/brotli-checker) makes that request for you from a
WatchFor probe location and prints the answer: Yes or No, plus the exact
encoding the server returned. No signup.

## What this tool answers

*Does this site hand Brotli-compressed responses to clients that ask for
it?* Reach for it right after enabling Brotli (the `ngx_brotli` module,
Apache's `mod_brotli`, a CDN setting), after moving hosts or CDNs, or when
PageSpeed Insights keeps pointing at transfer size. Your own browser's
DevTools only show what *your* connection got, often from a cache; this is
a fresh request from outside your network.

## A real example

### Checking Brotli compression after turning it on

The usual situation: someone flipped Brotli on and the site "feels the
same". Is the setting live, or did a proxy in between strip it? We ran the
[Brotli Checker](/brotli-checker) on two well-known sites to show both
answers.

First `www.cloudflare.com`:

![The Brotli Checker result for www.cloudflare.com: Brotli Yes, a green Brotli supported badge, Encoding br and a check time of 28 ms](/blog/how-to-check-brotli-compression-yes.webp)

**Yes**, encoding `br`. The server compressed its home page with Brotli.

Then `github.com`:

![The Brotli Checker result for github.com: Brotli No, an amber Not supported badge, Encoding shown as a dash and a check time of 106 ms](/blog/how-to-check-brotli-compression-no.webp)

**No**, and the encoding is a dash: when offered *only* Brotli, GitHub sent
the page uncompressed. That doesn't mean GitHub serves raw HTML to
browsers. Real browsers offer `gzip, deflate, br, zstd`, and when we offered
gzip as well (see the command-line section), GitHub answered with gzip.

How much does the difference weigh? We fetched both home pages three ways
from our own machine, with curl, a few minutes later:

| Site | Uncompressed | gzip | Brotli |
| --- | --- | --- | --- |
| www.cloudflare.com | 1,333,878 bytes | 301,392 bytes | 109,148 bytes |
| github.com | 576,666 bytes | 117,414 bytes | not offered |

**The answer:** Cloudflare's Brotli is live, and on that page it sends about
a third of the gzip bytes. GitHub doesn't serve Brotli on its home page but
does compress it with gzip, so it is a missed optimisation, not a broken
setting. Home-page HTML is generated per request, so your own numbers will
differ from run to run; the ratio is what to compare.

## How to read the results

| What you see | What it means |
| --- | --- |
| **Brotli · Yes / No** | Yes when the response's `Content-Encoding` contains `br`. No for anything else. |
| **Brotli supported / Not supported** | The same verdict as a badge: green for Yes, amber for No. Amber, not red: a site without Brotli still works. |
| **Domain** | What was checked. The tool fetches `https://<domain>/` and follows up to 10 redirects, so the answer is about the final page. |
| **Encoding** | The `Content-Encoding` header the server sent, word for word. A dash means no header: the body came back uncompressed. `gzip` here would mean the server ignored the Brotli offer and used gzip anyway. |
| **Check time** | How long the probe waited for the response headers, DNS and TLS included (28 ms for Cloudflare, 106 ms for GitHub from Vilnius). The body isn't downloaded, so it says nothing about page weight or compression speed. |

Only the domain is used, so the check always looks at the home page. If you
need to check a stylesheet or a script, use curl (below).

## More ways to use it

- **After enabling `ngx_brotli`.** A common miss: the module is loaded but
  `brotli_types` doesn't list your content type, or a proxy in front
  (load balancer, older CDN) re-encodes the response.
- **After moving to a new CDN or host.** Compression settings rarely
  migrate. Run it on the old and the new setup and compare.
- **When a PageSpeed report flags transfer size.** If the HTML is already
  `br`, the bytes are coming from somewhere else: images, fonts, scripts.
- **Checking a vendor.** Before you put a third-party landing page or docs
  site on your domain, see whether it compresses at all.

## Tips and gotchas

- **"No" is about Brotli, not compression in general.** The checker offers
  only `br` on purpose, so a gzip-only server answers uncompressed. Run the
  gzip curl below before concluding a site sends raw bytes; the
  [Gzip Compression Test](/gzip-test) page explains that fallback.
- **CDN edges decide, not your origin.** With a CDN in front, the edge
  compresses for the visitor; your origin may send gzip or nothing. Check
  the public URL, not the origin's.
- **Brotli only helps text.** HTML, CSS, JavaScript, JSON and SVG shrink a
  lot; JPEG, PNG, WebP, video and fonts in WOFF2 are already compressed.
  [Gzip vs Brotli](/blog/gzip-vs-brotli) has the background.
- **Browsers only ask for Brotli over HTTPS.** Testing a plain `http://`
  URL from a browser will never show `br`.
- **Keep the `Vary: Accept-Encoding` header.** It tells caches to store the
  Brotli and gzip copies separately, so a gzip-only client never receives a
  Brotli body.

To switch it on in nginx with the `ngx_brotli` module:

```nginx
brotli on;
brotli_comp_level 5;
brotli_types text/css application/javascript application/json image/svg+xml;
```

`text/html` is always compressed once `brotli on` is set; list the other
text types you serve. In Apache, `mod_brotli` does the same with
`AddOutputFilterByType BROTLI_COMPRESS text/html text/css application/javascript`.

## Check it from the command line too

Ask for Brotli only, as the checker does, and print the encoding:

```bash
curl -s -o /dev/null -D - -H 'Accept-Encoding: br' https://www.cloudflare.com/ | grep -i content-encoding
curl -s -o /dev/null -D - -H 'Accept-Encoding: br' https://github.com/ | grep -i content-encoding
```

```text
content-encoding: br
```

Only Cloudflare printed a line; GitHub sent no `Content-Encoding` at all.
Offer gzip too, the way a browser does, and GitHub falls back to gzip:

```bash
curl -s -o /dev/null -D - -H 'Accept-Encoding: br, gzip' https://github.com/ | grep -i content-encoding
```

```text
content-encoding: gzip
```

To measure the saving, compare the bytes on the wire for each encoding
(curl doesn't decompress unless you pass `--compressed`, so
`size_download` is the transferred size):

```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.cloudflare.com/
done
```

```text
identity: 1333878 bytes
gzip: 301392 bytes
br: 109148 bytes
```

Point the same loop at `/app.css` or a script bundle to check assets, which
the checker doesn't cover.

## Keep watching it

Compression settings tend to vanish quietly: a CDN migration, a new nginx
image without the module, a proxy upgrade. A
[compression monitor](/compression-monitoring) repeats this exact request on
a schedule, and its **Brotli Not Supported** rule warns you when the site
stops returning `br`.

## FAQ

**How do I know if my website uses Brotli?**
Open DevTools, select the page's document request in the Network tab and
look for `content-encoding: br` in the response headers, or run the free
checker or `curl -H 'Accept-Encoding: br' -I` against the URL.

**Is Brotli better than gzip?**
For text it usually produces smaller files at comparable speed, as the
Cloudflare numbers above show. Keep gzip enabled as the fallback for clients
that don't offer Brotli.

**Why does my server return gzip when Brotli is enabled?**
Either the request didn't offer `br` (plain HTTP, an old client, a proxy
that rewrites `Accept-Encoding`), the content type isn't in `brotli_types`,
or a layer in front recompresses the response. Check the public URL and the
origin separately to find the layer.

---

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