Brotli Compression Test — Verify Brotli Support

Sends an HTTPS GET request with Accept-Encoding: br and checks whether the server responds with Content-Encoding: br.

More Tools

Brotli Compression Test — Check Any Website for Brotli Support

Brotli Compression Test sends a live HTTPS GET request to any public domain with the Accept-Encoding: br request header. If the server supports Brotli compression (RFC 7932), it responds with Content-Encoding: br. The test detects this response header server-side, confirming whether the web server actively negotiates Brotli encoding with clients. Results reflect the live server configuration — not browser-cached state. No domain or result data is stored.

Property	Value
Standard	RFC 7932 — Brotli Compressed Data Format
Negotiation	`Accept-Encoding: br` → `Content-Encoding: br`
Requires HTTPS	Yes — all major browsers enforce HTTPS-only Brotli
Browser support	Chrome, Firefox, Safari, Edge — all versions since 2017
Compression gain vs Gzip	15–25% smaller at equivalent compression level

How to Test Brotli Compression Support

Verify Brotli is active on any domain in under 30 seconds.

Enter the Domain Name

Enter the domain name in the input field — for example, nginx.org or apache.org. No https:// prefix or path required.

Submit the Test

Click "Test Brotli Compression". The tool sends a live HTTPS GET request to the domain with the Accept-Encoding: br header.

Read the Result

SUPPORTED confirms the server returned Content-Encoding: br — Brotli is active. NOT SUPPORTED means the header was absent from the response.

Act on the Result

If NOT SUPPORTED, verify the server's Brotli module (ngx_brotli for Nginx, mod_brotli for Apache 2.4.26+) or check CDN compression settings.

What the Brotli Test Results Mean

Result	Meaning	Next Step
SUPPORTED	Server returned `Content-Encoding: br` — Brotli encoding is active and being negotiated correctly via the standard RFC 7932 mechanism.	Verify SSL certificate validity and HTTP/2 support are also configured for full modern-stack compliance.
NOT SUPPORTED	Server did not return `Content-Encoding: br`. The HTTPS connection succeeded but Brotli was not negotiated — Gzip or no compression is in use.	Install ngx_brotli (Nginx) or mod_brotli (Apache 2.4.26+), or enable Brotli compression in your CDN's settings panel.
Test Failed	Connection error — domain unreachable, DNS failure, HTTPS port 443 not open, or invalid SSL certificate.	Verify the SSL certificate is valid and the domain resolves correctly before re-testing.

Brotli vs Gzip — Technical Comparison

Property	Brotli	Gzip
Standard	RFC 7932	RFC 1952
Introduced	2015 (Google)	1992
Compression gain	15–25% smaller than Gzip	Baseline reference
Compression levels	0–11	1–9
Browser HTTPS enforcement	Yes — required by all major browsers	No — works over HTTP or HTTPS
Best for	Static HTML, CSS, JS, web fonts (TTF, WOFF)	Dynamic content, broad compatibility
Request header	`Accept-Encoding: br`	`Accept-Encoding: gzip`
Response header	`Content-Encoding: br`	`Content-Encoding: gzip`

How Brotli Compression Is Detected

Brotli is a lossless data compression algorithm specified in RFC 7932, built on a combination of the LZ77 algorithm, Huffman coding, and 2nd-order context modelling. HTTP content-encoding negotiation is defined in RFC 9110 §8.4: the client sends an Accept-Encoding request header listing supported algorithms; the server selects one and identifies it via the Content-Encoding response header.

The Brotli Compression Test sends a GET request to port 443 (HTTPS) with the header Accept-Encoding: br. If the server returns Content-Encoding: br, Brotli is confirmed active. The request is issued from an external server, so results reflect the server's live response as seen by an external client — not a browser cache, local resolver, or CDN edge cache.

All major browsers — Chrome, Firefox, Safari, and Edge — only advertise Accept-Encoding: br over HTTPS connections. RFC 7932 does not technically require TLS, but browser enforcement makes HTTPS a practical requirement for Brotli delivery in production. The test uses HTTPS exclusively for this reason.

Do it yourself

How to Test Brotli Compression Without an Online Tool

Use curl to send the same Accept-Encoding: br header the tool sends, and inspect the response headers directly from your terminal. If content-encoding: br appears in the output, Brotli is active.

Windows Command Prompt

curl -s -o NUL -D - -H "Accept-Encoding: br" https://example.com

Scan the output for content-encoding: br. If the line is absent, the server is not returning Brotli encoding.

Windows PowerShell

(Invoke-WebRequest -Uri "https://example.com" -Headers @{"Accept-Encoding"="br"}).Headers["Content-Encoding"]

Returns br if Brotli is active. Returns nothing if the header is absent.

Mac / Linux curl

curl -s -o /dev/null -D - -H "Accept-Encoding: br" https://example.com | grep -i "content-encoding"

The online tool issues this same request from an external server. Results may differ from local testing if your network path or DNS resolver routes to a different CDN edge node than the external vantage point.

Common Uses for the Brotli Compression Test

Post-deployment verification. A DevOps engineer adds the ngx_brotli module to an Nginx configuration and deploys to staging. Before shifting production traffic, they use the Brotli Compression Test to confirm the origin server returns Content-Encoding: br — verifying the module loaded correctly and that Brotli negotiation is working end-to-end, not just locally.

PageSpeed audit follow-up. A web developer receives a Lighthouse report flagging "Enable text compression." The Brotli Compression Test determines whether the CDN layer is already serving Brotli or whether origin-server module installation is required — narrowing the fix before any server changes are made.

CDN migration validation. A site reliability engineer migrating from one CDN to another tests production domains immediately after DNS cutover. The Brotli Compression Test confirms the new CDN edge nodes correctly advertise Content-Encoding: br, catching missing compression configuration before user traffic is affected.

Frequently Asked Questions

What does the Brotli Compression Test detect, exactly?

Brotli Compression Test sends a GET request with Accept-Encoding: br and checks whether the server responds with Content-Encoding: br. If that response header is present, Brotli compression is active and being negotiated correctly. The test confirms encoding negotiation only — it does not measure compression ratio, file size reduction, or decompression speed.

Why does my site show NOT SUPPORTED when Brotli is configured?

Several conditions can produce a false negative: some CDNs serve Brotli only to browser User-Agent strings; Brotli may be active on the CDN edge but not on the origin server; or the tested domain may serve non-compressible content on its root path. Cross-check from your terminal: curl -s -o /dev/null -D - -H "Accept-Encoding: br" https://yourdomain.com | grep -i content-encoding.

What is the difference between Brotli and Gzip?

Brotli (RFC 7932) achieves 15–25% better compression ratios than Gzip (RFC 1952) on HTML, CSS, and JavaScript. Gzip has universal server and browser support since the 1990s and works over HTTP or HTTPS. Brotli requires HTTPS in all major browsers, though RFC 7932 itself does not mandate TLS. Most modern servers configure both algorithms and serve Brotli when the client advertises Accept-Encoding: br.

How accurate is the Brotli Compression Test?

The test accurately detects Content-Encoding: br in the server's live response for most public domains. Accuracy may be reduced for domains that restrict Brotli to browser User-Agent strings, domains behind bot-detection or CAPTCHA systems, or CDNs with edge-only Brotli that do not propagate the encoding header to external requests. Confirm results alongside your browser's DevTools Network tab for definitive verification.

Does Brotli require HTTPS?

RFC 7932 does not mandate TLS, but Chrome, Firefox, Safari, and Edge exclusively negotiate Brotli over HTTPS connections — no major browser advertises Accept-Encoding: br over plain HTTP. A server can technically serve Brotli over HTTP, but no browser client will request it. The Brotli Compression Test uses HTTPS exclusively, matching real-world browser behavior.

Do you store the domains I test?

No. Each request is processed server-side in real time. No domain names, IP addresses, or test results are logged, stored, or shared after the response is returned to your browser.

Related Guides

Guide What Is a VPN?

VPN tunnels and privacy proxies route traffic through intermediate nodes, which can affect which CDN edge is reached and which compression headers are returned. Understanding VPN routing helps diagnose why Brotli results differ across networks or geographic locations.

Guide What Is a Proxy Server?

Forward and reverse proxies interact with HTTP header negotiation. A misconfigured proxy can strip Accept-Encoding request headers before they reach the origin server, preventing Brotli negotiation even when the origin is fully configured.