Back to all free tools

Brotli Checker

Check whether a site serves Brotli-compressed responses (Content-Encoding: br) for faster page loads.

Result

No result yet

Enter the inputs above and press Run. Results appear here in a moment.

Monitor this 24/7 — get alerts on the first failure.

Start free

Only run these tools against systems you own or are authorized to test. Using them to scan or probe systems without permission violates our Terms.

What is Brotli Checker?

Brotli is a compression algorithm from Google that consistently beats gzip on text — HTML, CSS, JavaScript, JSON — by 15-25%. Fewer bytes over the wire means faster first paint, lower bandwidth bills, and a measurable nudge to Core Web Vitals (and therefore search ranking). Almost every browser has supported it for years, so the only question is whether your server or CDN actually sends it.

This tool asks a site for a Brotli-compressed response (the way a real browser does, by advertising Accept-Encoding: br) and reports whether the server honoured it — i.e. whether the response came back with Content-Encoding: br, or fell back to gzip or no compression at all.

How it works

It reproduces exactly what a browser negotiates on every request:

  1. 1Advertise Brotli support — Send a request with Accept-Encoding offering br (alongside gzip), telling the server the client can decode Brotli — the same handshake your browser performs.
  2. 2Read what came back — Inspect the Content-Encoding response header. br means the server compressed with Brotli; gzip means it fell back to the older algorithm; absent means the response wasn't compressed at all.
  3. 3Report the result — Yes when Brotli was served, with the exact Content-Encoding value; No otherwise. Compression is content-negotiated per response, so the answer reflects what this specific resource returned.

Compression is opportunistic: the server only Brotli-encodes when the client asks for it AND the content type is worth compressing. A No here usually means a config gap (Brotli not enabled, or only enabled for pre-compressed static files), not that Brotli is unavailable.

When you'd use it

Confirm Brotli is live after enabling it

You flipped on brotli on; in nginx, or ticked the Brotli box in your CDN dashboard. Don't trust the toggle — verify the wire. This tells you immediately whether real responses now carry Content-Encoding: br.

Performance audit

Pages feel heavy and Lighthouse flags "enable text compression." Check whether you're shipping uncompressed or gzip-only responses where Brotli would shave 15-25% off the transfer size — one of the cheapest performance wins available.

CDN configuration check

Your origin serves Brotli but your CDN re-compresses or strips it (or vice versa). Checking the public hostname tells you what visitors actually receive after the CDN layer, not what your origin intended.

Debugging a Core Web Vitals regression

LCP crept up after an infra change. Oversized text payloads are a frequent cause — confirm compression didn't silently revert to gzip or off during the migration.

Pre-launch checklist

Before a launch, verify the boring-but-impactful basics: HTTPS, caching headers, and text compression. Brotli on the main document and your CSS/JS bundles is a one-line config that pays off on every page load.

Reading the result

Brotli supported (yes / no)

Yes means the server returned Content-Encoding: br when offered Brotli — it's live. No means it didn't: either it fell back to gzip, or sent the response uncompressed. No is a finding worth acting on, not an error.

Content-Encoding

The exact value the server returned. br is Brotli; gzip is the older fallback (still good, just not optimal for text); empty means no compression was applied to this response.

Check time

How long the request took. Brotli at high compression levels costs more CPU on dynamic responses — most sites pre-compress static assets to avoid that cost on every request.

Common pitfalls

Brotli only happens over HTTPS

Browsers only advertise br on secure connections, and most servers only offer it over TLS. If you test a plain http:// URL you may see gzip or nothing even on a Brotli-capable server — always check the https:// origin.

Only compressible content gets compressed

Brotli (like gzip) is for text — HTML, CSS, JS, JSON, SVG, fonts. Already-compressed binaries (JPEG, PNG, WebP, MP4, ZIP) are not re-compressed, and shouldn't be. A No on an image URL is correct behaviour; test an HTML or CSS URL.

Static vs. dynamic Brotli

Many servers Brotli-compress only pre-built static files (where they can afford max compression once) and serve dynamic HTML with gzip — because Brotli at high levels is CPU-expensive per request. So your .css may be br while the document is gzip. Check the specific resource you care about.

The CDN has the final say

Even with Brotli enabled at the origin, a CDN can decompress and re-serve with gzip, or strip encoding entirely. What the visitor receives is whatever the last hop sent — so test the public hostname, not just the origin.

Run Brotli Checker on every change, not just once.

Get alerts the moment something breaks — across HTTP, DNS, SSL, RDAP, ping, blacklist and more. Free forever for 10 monitors. No card.

Start free

Frequently asked questions

Is Brotli actually better than gzip?
For text (HTML/CSS/JS/JSON), yes — typically 15-25% smaller than gzip at comparable speed, and the gap widens at higher compression levels for static assets. For already-compressed binaries (images, video) neither helps. The practical win is on your text payloads, which is most of what blocks first paint.
Why does it say not supported when I enabled Brotli?
Common causes: you tested an http:// URL (Brotli is negotiated on HTTPS), you tested a non-compressible resource like an image, the server only Brotli-compresses static files and you hit dynamic HTML, or a CDN in front re-compressed the response with gzip. Test the https:// document or a .css/.js URL through the public hostname.
Does Brotli work over plain HTTP?
In practice, no. Browsers only advertise Accept-Encoding: br on secure (HTTPS) connections, and servers follow suit. Always check the HTTPS version of a URL.
What content should be Brotli-compressed?
Text-based, compressible types: HTML, CSS, JavaScript, JSON, XML, SVG, and font files. Don't compress already-compressed formats (JPEG, PNG, WebP, MP4, woff2 is already compressed) — it wastes CPU for no gain.
Which browsers support Brotli?
All current major browsers — Chrome, Firefox, Safari, Edge — have supported Brotli over HTTPS for years. Server/CDN support is the bottleneck, not the client, which is why verifying the response header is the useful check.
How do I enable Brotli?
On nginx, the ngx_brotli module (brotli on; brotli_types ...;). On a CDN (Cloudflare, Fastly, CloudFront via a function, etc.) it's usually a single toggle or a behaviour setting. After enabling it, re-run this check against the public hostname to confirm responses now return Content-Encoding: br.

Related web tools