Brotli vs. Zstandard (Zstd): A Practical Compression Comparison

, function(), or common English words are already known before the actual compression starts, rather than having to be learned from the document being compressed itself.

Zstandard follows a similar algorithmic foundation of entropy coding and dictionary search, but was built from the ground up for speed and offers a very wide range of compression levels, from 1 to 22. Zstd does not ship a fixed, web-specific default dictionary, but it does support training custom, project-specific dictionaries, which can provide a real advantage for many small, structurally similar responses such as JSON API payloads, an advantage a generic dictionary simply cannot offer.

3. Compression ratio compared: HTML, CSS, JavaScript, and JSON

At high compression levels, Brotli delivers a slightly better compression ratio than Zstd for classic web content like HTML and CSS files in most benchmarks at a comparable speed level, largely thanks to the built-in web dictionary. At Brotli quality level 11, the highest available, typical HTML documents can be compressed to a ratio that beats Gzip at its highest level by roughly 15 to 20 percent, while Zstd at its top level 22 lands roughly on par with Brotli, sometimes trailing it slightly.

The gap narrows for very large, highly repetitive files, because both methods then find enough context within the document itself to produce good results independent of any shipped dictionary. For small responses, such as short API payloads under ten kilobytes, a Zstd dictionary trained on the project's own data can actually beat Brotli on compression ratio, because it is tailored exactly to the real response format rather than to generic web content.

4. Encoding and decoding speed compared

The clearest difference between the two methods shows up not in compression ratio but in speed. Brotli at quality level 11 is computationally expensive and unsuitable for dynamic, per-request compression, because compression time for larger files can reach several hundred milliseconds. Zstd achieves noticeably shorter encoding times even at high compression levels and, at its lower levels, offers a range where usable compression ratios can be achieved at a fraction of Brotli's CPU cost.

For decompression, which happens in the browser and matters for perceived load time, Zstd is ahead by design, since decompression speed was a core goal of the format from the start. For static assets that are precompressed once at build time and then only ever served, encoding speed is practically irrelevant, which is why the highest Brotli quality level is almost always worth it in that case. For dynamically generated content that has to be compressed fresh on every request, Zstd at a medium compression level is often the more practical choice.

5. Current browser support status for Zstd content encoding

Brotli has been supported over HTTPS by all relevant browsers for years and can be deployed in production without hesitation, with a fallback mechanism being little more than a formality. For Zstandard as an HTTP content encoding the picture is more nuanced: Chromium-based browsers like Chrome and Edge have supported zstd content encoding since version 123, and Firefox followed with version 126, so support across the two most widely used browser engines can now be considered production ready.

Safari still lags behind on native Zstd content encoding support, which means the rollout cannot simply be flipped on across the board and instead has to be negotiated through the Accept-Encoding header sent by the client. A server offering Zstd must therefore still keep both Brotli and Gzip available as fallbacks, so clients without Zstd support do not end up receiving a response they cannot decode. This situation should keep improving with future browser versions, but it is currently an important reason why running Zstd alone, without a Brotli fallback, is not yet advisable.

6. Nginx configuration for Brotli

Brotli is not part of Nginx core and has to be added through the dynamic ngx_brotli module, either by compiling it in with the corresponding module flag or by using a prebuilt Nginx image that already ships the module. For static assets that were already precompressed into a .br file at build time, brotli_static enables serving the precompressed file directly, without the server having to compress at runtime, which saves CPU load and shortens response time.

For dynamically generated content where no precompressed file exists, runtime Brotli compression takes over, though usually at a lower quality level than at build time to keep server CPU load in check. The configuration below shows both cases combined, precompressed static files together with a moderate compression level for dynamic responses.

http {
    # Serve precompressed .br files directly when available
    brotli_static on;

    # Dynamic compression for responses without a precompressed file
    brotli on;
    brotli_comp_level 5;
    brotli_min_length 512;
    brotli_types
        text/plain
        text/css
        text/xml
        application/json
        application/javascript
        application/xml+rss
        image/svg+xml;
}

7. Nginx configuration for Zstd and running both methods in parallel

Zstandard support in Nginx likewise requires an additional module, such as ngx_http_zstd_module, which, analogous to ngx_brotli, offers both static serving of precompressed .zst files and dynamic runtime compression. To make sure each client gets the best format it can handle, Nginx evaluates the Accept-Encoding header sent by the client and automatically picks the best supported format in the order Zstd, then Brotli, then Gzip, provided all three modules are active at once.

The important part is configuring both a precompressed variant and a dynamic fallback for every supported format, so no client is left empty-handed. For static assets that means the build process needs to produce both a .br and a .zst variant of every file, which lengthens the build slightly but incurs no additional CPU cost at runtime, since Nginx simply serves the matching file.

http {
    # Zstd precompressed files and dynamic compression
    zstd_static on;
    zstd on;
    zstd_comp_level 12;
    zstd_min_length 512;
    zstd_types
        text/plain
        text/css
        application/json
        application/javascript
        image/svg+xml;

    # Negotiation order zstd, then brotli, then gzip
    # is determined by the client's Accept-Encoding header
}

8. When a switch or parallel support actually pays off

For most online shops and content sites, fully switching from Brotli to Zstd is not currently worthwhile, because Brotli still delivers a better compression ratio for static assets and is reliably supported by all relevant browsers. Running both in parallel makes more sense: Brotli at its highest quality level for precompressed static assets like CSS and JavaScript bundles, and Zstd for cases where compression speed genuinely matters, such as dynamically generated API responses under high request volume.

Zstd becomes especially worthwhile once servers are under heavy CPU load and dynamic content has to be recompressed on every request, because its shorter encoding times directly protect server capacity. For a project made up mostly of static, well cacheable assets, Brotli with precompressed files remains the simpler and more efficient solution, while parallel Zstd support pays off mainly where clients can already make use of it and server load is a genuine concern.

9. A decision guide side by side

The table below summarizes the key differences between Brotli and Zstd to help estimate more quickly, for a concrete project, which method is the better choice for which use case.

10. Summary

11. FAQ: Brotli vs. Zstd: The Essentials at a Glance