Brotli Compression on IIS

What you need

IIS compression is pluggable: the static and dynamic compression modules call a scheme provider DLL for each encoding. The built-in provider, %windir%\system32\inetsrv\gzip.dll, implements gzip and deflate only. Brotli comes from IIS Compression, a free Microsoft download that contains two providers:

• iisbrotli.dll — a Brotli (br) scheme provider.
• iiszlib.dll — a zlib-based gzip/deflate provider that can replace the built-in gzip.dll.

Both are installed under %ProgramFiles%\IIS\IIS Compression\. They do not replace the IIS compression modules; you still need the Static and/or Dynamic Content Compression features installed (see installing IIS compression).

Step 1: install IIS Compression

Download the installer from the IIS Compression page on iis.net (https://www.iis.net/downloads/microsoft/iis-compression), choosing the 64-bit package for a 64-bit server, and run it as an administrator. A silent install works the same way as any MSI:

msiexec /i iiscompression_amd64.msi /quiet /norestart
iisreset

The installer registers the new providers in applicationHost.config. Always check the result rather than assuming it, as described in step 2.

Step 2: check the scheme configuration

Open %windir%\system32\inetsrv\config\applicationHost.config (or use the Configuration Editor in IIS Manager on system.webServer/httpCompression) and look for the scheme elements. A working setup looks like this:

<httpCompression directory="%SystemDrive%\inetpub\temp\IIS Temporary Compressed Files">
    <scheme name="br" dll="%ProgramFiles%\IIS\IIS Compression\iisbrotli.dll"
            dynamicCompressionLevel="5" staticCompressionLevel="11" />
    <scheme name="gzip" dll="%ProgramFiles%\IIS\IIS Compression\iiszlib.dll"
            dynamicCompressionLevel="4" staticCompressionLevel="9" />
    <!-- staticTypes / dynamicTypes as before -->
</httpCompression>

• Put br first. When a client accepts several schemes equally, the order of the scheme elements decides which one IIS uses. Listing gzip first means browsers keep getting gzip even though Brotli is installed.
• Levels. Brotli levels run from 0 to 11. Level 11 is fine for static files, which IIS compresses once and caches. For dynamic responses, which are compressed on every request, stay around 4–6; higher levels cost a lot of CPU for little gain.
• If you prefer to keep Microsoft's original gzip provider, leave the gzip scheme pointing at %windir%\system32\inetsrv\gzip.dll; Brotli works either way.

You can also add the scheme from the command line:

%windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/httpCompression /+"[name='br',dll='%ProgramFiles%\IIS\IIS Compression\iisbrotli.dll',dynamicCompressionLevel='5',staticCompressionLevel='11']" /commit:apphost

Step 3: verify

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

Test over HTTPS. Browsers only advertise br on secure connections, so a site served over plain HTTP will keep receiving gzip from browsers even when IIS is configured correctly. Remember also that IIS compresses a static file only after it has been requested more than once in a short period (the frequentHitThreshold setting), so repeat the request before concluding that Brotli is not working.

Do not fake Brotli with URL Rewrite

Some older tutorials suggest an outbound URL Rewrite rule that sets the Content-Encoding response header to br whenever {HTTP_ACCEPT_ENCODING} contains br. That rule only changes the label, not the bytes. Clients then try to Brotli-decode a gzip or uncompressed body and fail with errors such as ERR_CONTENT_DECODING_FAILED or "truncated brotli stream". If you have such a rule, remove it; the scheme provider sets the correct header itself. The same goes for adding Vary: Accept-Encoding as a custom header: IIS adds it to compressed responses already, and a second copy is redundant. See content decoding errors for how to recognise the symptoms.

Azure App Service and ASP.NET Core

On Azure App Service you cannot run an MSI on the underlying IIS instance. Options for Brotli there are:

• A site extension. Community-maintained App Service site extensions exist that register the IIS Compression providers for your app (Windows plans only). They work, but you depend on a third party keeping the extension current, so review its source and update history before relying on it.
• ASP.NET Core response compression. The built-in Response Compression middleware (AddResponseCompression with BrotliCompressionProvider and GzipCompressionProvider) compresses in your application and works on any hosting plan, including Linux. Make sure IIS's own dynamic compression is off for those responses so nothing is compressed twice.
• Compress at the edge. If the app sits behind Azure Front Door or another CDN, let the edge compress and keep the app simple; see CDN compression.

Pick one of these, not several: stacking app-level compression, a site extension and edge compression mostly adds CPU and complexity.

When Brotli is still missing

• Content-Encoding is gzip: check scheme order and that the request is HTTPS.
• No compression at all: check that the MIME type is in staticTypes/dynamicTypes and that the compression features are installed and enabled (install guide).
• Brotli disappears behind a proxy or WAF: some intermediaries rewrite Accept-Encoding to gzip or strip br before the request reaches IIS. Log the header IIS actually receives (the HTTP_ACCEPT_ENCODING server variable) to confirm.