HTTP8 min read

Gzip vs Brotli Compression

Understand the differences between Gzip and Brotli, compression ratios, performance trade-offs and HTTP content compression best practices.

Published: 2026-08-07

HTTP compression reduces the size of data transferred between web servers and browsers, allowing pages to load faster while consuming less bandwidth. Two of the most common compression algorithms used on today's web are Gzip and Brotli. Both compress text-based resources effectively, but they differ in compression ratio, speed and typical use cases.

Modern browsers support both algorithms and automatically negotiate which one to use through the HTTP Accept-Encoding request header.

What Is HTTP Compression?

HTTP compression reduces the amount of data transmitted across the network by encoding resources before they are sent to the client. Browsers automatically decompress supported responses after downloading them, making the process transparent to users.

Why Compression Matters

Smaller responses reduce download times, improve page loading speed and decrease bandwidth usage. Compression is particularly beneficial for HTML, CSS, JavaScript, JSON, XML and other text-based content.

Reduce page load times.
Lower bandwidth consumption.
Improve user experience.
Decrease server data transfer costs.
Improve performance on slower networks.

What Is Gzip?

Gzip is a widely supported compression algorithm that has been used on the web for decades. It provides good compression while remaining fast enough for dynamic content generated in real time.

What Is Brotli?

Brotli is a newer compression algorithm developed to achieve better compression ratios than Gzip, particularly for static web assets. Although higher compression levels require more CPU time during compression, browsers decompress Brotli content efficiently.

How Compression Works

Browser Sends Request
↓
Accept-Encoding: br, gzip
↓
Server Selects Compression
↓
Compressed Response Sent
↓
Browser Decompresses Automatically

Compression Comparison

Feature	Gzip	Brotli
Compression Ratio	Good	Excellent
Compression Speed	Fast	Slower at high levels
Decompression Speed	Fast	Fast
Browser Support	Excellent	Excellent in modern browsers

Typical HTTP Headers

Compression negotiation is performed using standard HTTP headers exchanged between the client and server.

Accept-Encoding: br, gzip

Content-Encoding: br

Which Files Should Be Compressed?

Compression provides the greatest benefit for text-based resources. Files that are already compressed, such as JPEG images, MP4 videos or ZIP archives, usually gain little or no benefit from additional HTTP compression.

💡 Enable Brotli for static assets whenever possible while keeping Gzip available as a fallback for clients that do not support Brotli.

⚠️ Avoid compressing already compressed file formats because additional compression typically wastes CPU resources without significantly reducing file size.

Compression Levels

Both Gzip and Brotli support multiple compression levels. Higher levels usually produce smaller files but require more CPU time during compression. Lower levels compress faster but typically achieve lower compression ratios.

Compression Level	Typical Effect
Low	Fast compression, larger output
Medium	Balanced speed and compression
High	Smaller output, higher CPU usage

Dynamic vs Static Content

Dynamic content is generated for each request, making compression speed more important. Static files can often be compressed in advance, allowing servers to use higher compression levels without affecting request processing time.

Content Type	Recommended Compression
Dynamic HTML	Moderate Gzip or Brotli
Static CSS	High-level Brotli
Static JavaScript	High-level Brotli
JSON API Responses	Gzip or Brotli

Browser Negotiation

Browsers advertise supported compression algorithms using the Accept-Encoding request header. The server selects the most appropriate algorithm and indicates its choice using the Content-Encoding response header.

Performance Considerations

Brotli generally produces smaller files than Gzip, reducing download time, especially for static assets. However, very high Brotli compression levels require more processing time and are best suited for files compressed ahead of time rather than on every request.

Compression and Caching

Compressed resources work well with browser and CDN caching. Once a compressed response is cached, it can be served repeatedly without requiring recompression, improving both server efficiency and response times.

When Gzip Is Still a Good Choice

Although Brotli often achieves better compression, Gzip remains an excellent option because of its broad compatibility, fast compression speed and efficient handling of dynamically generated responses.

When Brotli Provides the Most Benefit

Brotli is particularly effective for static assets that rarely change. Precompressing HTML, CSS and JavaScript with high Brotli compression levels can significantly reduce transfer size without affecting runtime server performance.

Scenario	Recommended Algorithm
Static website	Brotli
Dynamic application	Gzip or moderate Brotli
Legacy compatibility	Gzip
Modern browsers	Brotli with Gzip fallback

💡 For production websites, precompress static assets with Brotli and enable Gzip as a fallback. This combination provides excellent performance across modern and older browsers.

⚠️ Compression reduces network traffic but increases CPU usage during encoding. Test server performance before selecting aggressive compression levels for high-traffic applications.

Common Mistakes

HTTP compression is one of the easiest performance optimizations to enable, yet it is sometimes configured inefficiently. Compressing inappropriate file types or choosing unsuitable compression levels can waste CPU resources without providing meaningful performance benefits.

Compressing already compressed files such as JPEG, PNG, MP4 or ZIP archives.
Using maximum Brotli compression for every dynamic response.
Enabling Brotli without providing Gzip as a fallback when compatibility is required.
Forgetting to verify the Content-Encoding response header.
Ignoring caching when serving compressed resources.
Assuming compression alone solves website performance issues.

Best Practices

Enable Brotli for static assets whenever possible.
Keep Gzip available as a fallback for unsupported clients.
Compress HTML, CSS, JavaScript, JSON and XML responses.
Avoid compressing files that are already efficiently compressed.
Combine compression with browser and CDN caching.
Measure performance before changing compression levels.

💡 The best compression strategy is usually to precompress static resources with Brotli at a high compression level while compressing dynamic responses with moderate settings that balance CPU usage and response time.

⚠️ Compression reduces transfer size but cannot compensate for oversized images, excessive JavaScript, slow database queries or inefficient application logic. Comprehensive optimization remains essential for high-performance websites.

Frequently Asked Questions

Is Brotli better than Gzip?

For most static web assets, yes. Brotli generally produces smaller compressed files while maintaining fast decompression. Gzip remains an excellent choice for compatibility and for compressing dynamic content efficiently.

Do browsers support Brotli?

Yes. All major modern browsers support Brotli. Servers commonly provide Gzip as a fallback for older clients that do not support Brotli.

Should images be compressed with Gzip or Brotli?

Usually not. Formats such as JPEG, PNG, WebP, AVIF and MP4 are already compressed. Additional HTTP compression typically provides little benefit while consuming extra CPU resources.

Can compression improve SEO?

Indirectly, yes. Smaller responses can reduce page load times, improving user experience and Core Web Vitals, which may contribute positively to search engine rankings.

Should dynamic API responses be compressed?

Yes. JSON, XML and other text-based API responses often compress very well, reducing bandwidth usage and improving response times, especially for larger payloads.

Helpful HTTP Tools

A Cache-Control Generator helps configure browser and CDN caching alongside compressed responses, an HTTP Header Viewer displays Content-Encoding and related HTTP headers for verification, a Content-Type Finder identifies MIME types to determine whether resources should be compressed, an HTTP Response Formatter improves the readability of raw HTTP responses during testing, and an Nginx Config Generator helps create server configurations that enable Gzip or Brotli compression for production deployments.

Conclusion

Both Gzip and Brotli play important roles in modern web performance. Gzip offers excellent compatibility and fast compression, while Brotli delivers superior compression ratios for many text-based resources, particularly static assets. By selecting the appropriate algorithm, enabling browser caching and serving compressed responses correctly, websites can reduce bandwidth usage, improve page load times and provide a faster experience for users across a wide range of devices and network conditions.