Web compression: how gzip and Brotli shrink the web

Web servers rarely send HTML, CSS and JavaScript as-is. They compress the text first, and the browser decompresses it on arrival. The two formats you meet most are gzip and Brotli. Both make pages smaller and load faster, but they work a little differently — and Brotli is usually better for the text-heavy files that make up most websites.

Why servers compress text

Plain text is repetitive. The same words, HTML tags, CSS properties and JavaScript identifiers appear again and again. Compression algorithms replace that repetition with shorter references, so a 200 KB script might arrive as 50 KB and be rebuilt in the browser. Less data over the wire means a faster first paint, especially on slow or mobile connections. Compression is negotiated per request: the browser lists what it accepts in Accept-Encoding, and the server answers with the algorithm it chose in Content-Encoding.

How gzip works

gzip is the older, near-universal format. Technically it wraps the DEFLATE algorithm (defined in RFC 1951) with a header and a 32-bit CRC checksum (defined in RFC 1952). DEFLATE combines the LZ77 method — finding repeated strings and pointing back to earlier copies — with Huffman coding, which assigns shorter codes to common bytes. Because gzip is old and simple, every browser and server supports it, and it compresses quickly even for freshly generated, dynamic responses.

How Brotli works

Brotli (defined in RFC 7932 by Google engineers J. Alakuijala and Z. Szabadka) also combines LZ77 with Huffman coding, so it is built on the same ideas as DEFLATE. The difference is a large, pre-defined dictionary: Brotli ships with roughly 1,200 common words and phrases drawn from web text, HTML, CSS and JavaScript. When it meets a familiar fragment — a frequent tag, a property name, a library call — it can reference the dictionary instead of repeating the bytes. RFC 7932 describes its efficiency as "comparable to the best currently available general-purpose compression methods."

Brotli vs gzip: the practical difference

The Brotli dictionary pays off most on web content. Wikipedia summarizes independent comparisons showing that, relative to gzip, JavaScript compressed with Brotli is roughly 15% smaller, HTML around 20% smaller, and CSS around 16% smaller. Brotli also has 11 quality levels (0–11); higher levels compress more but take longer, so Brotli is usually applied to static assets that are pre-compressed once at build time. gzip compresses faster at every level, which keeps it the better choice for responses generated on the fly. In short: gzip is the safe, fast default; Brotli is the stronger choice for pre-built CSS, JS and HTML.

Browser support

gzip has been supported by every browser for decades. Brotli (br in the Content-Encoding header) is supported by all current versions of Chrome, Firefox, Safari and Edge. A server that supports both simply sends Brotli to browsers that ask for it and falls back to gzip for the rest.

FAQ

What is the difference between gzip and Brotli?

Both are lossless text compressors built on LZ77 and Huffman coding. Brotli adds a large pre-built dictionary of common web words and phrases, which lets it compress HTML, CSS and JavaScript more tightly — Wikipedia cites roughly 15–20% smaller files than gzip for typical web assets.

Is Brotli better than gzip?

For static, text-heavy assets such as CSS and JavaScript, Brotli usually produces smaller files than gzip. gzip compresses faster and is supported everywhere, so it remains a strong choice for dynamically generated responses. Many servers send Brotli to capable browsers and gzip as a fallback.

How does the browser know which compression to use?

The browser advertises supported algorithms in the Accept-Encoding request header (for example gzip, br); the server replies with the one it used in the Content-Encoding response header. The browser then decompresses the body before rendering.

Can compression make a website slower?

Compression itself adds a little CPU work on the server and a little on the client, but the saved bytes almost always outweigh that cost on text. The main caveat is Brotli's highest quality levels, which are slow; that is why Brotli is normally pre-applied to static files rather than computed per request.

Summary

gzip and Brotli both shrink web text using LZ77 and Huffman coding, but Brotli's built-in dictionary gives it an edge on HTML, CSS and JavaScript. gzip is the universal, fast default; Brotli is the stronger option for pre-compressed static assets, and every modern browser supports it. Pick a host or server that negotiates both, and your pages ship fewer bytes without changing a line of your code.