Why WOFF2 Was Created: Brotli Compression and Web Font Performance

The Limitations of WOFF

WOFF 1.0, standardized in 2012, was a significant step forward for web fonts. It used zlib — the same compression algorithm behind gzip — to compress TrueType and OpenType fonts, typically achieving 40% file size reduction from the uncompressed source. However, as the web matured and mobile usage exploded, the performance demands on web fonts increased dramatically.

Google's research showed that font files were among the largest render-blocking resources on many web pages. The median web page loaded 3-4 font files totaling 100-300 KB compressed. On 3G mobile connections common in developing markets during 2012-2015, this could add 1-3 seconds to first contentful paint. Every kilobyte saved translated directly into better user experience for millions of people.

The fundamental limitation of WOFF 1.0 was that it applied zlib to raw font table data without any preprocessing. Font data has highly predictable internal structures — glyph coordinates follow geometric patterns, metrics tables have regular shapes, and character mapping data is largely sequential — but zlib was never designed to exploit these domain-specific patterns. A compressor that understood font internals could do significantly better.

Google's engineers, led by Khaled Hosny and Rod Sheeter within the Google Fonts team, began exploring whether a font-specific compression scheme could materially improve on zlib. The key insight was that font data has predictable internal structures that a specialized preprocessor could reorganize before compression, making the resulting data stream far more amenable to general-purpose compression algorithms.

Google's Brotli Innovation

Brotli is a general-purpose compression algorithm developed by Google engineers Jyrki Alakuijala and Zoltán Szabadka, initially released in 2013 specifically for WOFF2 compression. Brotli was later generalized for HTTP content encoding and accepted by all major browsers between 2016 and 2017. For WOFF2, Google combined Brotli with font-specific preprocessing to achieve compression far beyond what either technique could accomplish alone.

The key advantage of Brotli over zlib is its use of a substantially larger context window — up to 16 MB compared to zlib's 32 KB. This allows Brotli to find and exploit repeated patterns across much longer distances in the data stream. Brotli also uses a more sophisticated context model that predicts likely byte values based on surrounding data, achieving better compression ratios at comparable or faster decompression speeds.

Brotli additionally uses a predefined static dictionary of approximately 120,000 common substrings drawn from a large corpus of web content. While this dictionary is less relevant for binary font data than for HTML and JavaScript, it contributes to Brotli's overall compression advantage. The combination of larger context windows, better modeling, and dictionary-based encoding makes Brotli approximately 20-26% more effective than zlib at equal compression levels on typical web content.

For WOFF2 specifically, the gains are even larger because the font-specific preprocessing step transforms the data into a form that Brotli can compress exceptionally well. The combination of the glyph transform (described in the next section) and Brotli results in WOFF2 files that are typically 25-30% smaller than equivalent WOFF files. For some fonts — particularly those with large glyph sets like CJK fonts — the improvement can exceed 35%.

The WOFF2 Glyph Transform

The secret weapon of WOFF2 is its glyph transform preprocessing step. Before Brotli compression is applied, WOFF2 restructures the TrueType glyph data (the 'glyf' table) to be more compressor-friendly. This transformation is the single most important technical innovation in WOFF2, accounting for roughly half of its improvement over WOFF 1.0.

In a standard TrueType font, each glyph's outline data is stored as a sequence of contours, where each point contains a flag byte (indicating whether the point is on-curve or off-curve), an x-coordinate, and a y-coordinate. These three data types are interleaved in memory for each point, then repeated for each contour, then repeated for each glyph. This organization makes sense for random access but is terrible for compression, because flags, x-coordinates, and y-coordinates have very different statistical distributions.

The WOFF2 glyph transform separates glyph data into parallel streams: one stream for all flags across all glyphs, one for all x-coordinates, one for all y-coordinates, and one for composite glyph information. This separation groups similar data together, creating much longer runs of statistically similar bytes that Brotli can model and compress far more efficiently.

The transform also applies delta encoding to glyph coordinates. Rather than storing the absolute x and y position of each point, WOFF2 stores the difference between consecutive point positions. Because font outlines typically consist of smooth curves with gradually changing coordinates, these deltas are usually small numbers clustered near zero — exactly the kind of data that compresses exceptionally well.

Additionally, WOFF2 applies transforms to the 'loca' table (which indexes the position of each glyph in the 'glyf' table) and the 'hmtx' table (horizontal metrics). These tables have highly predictable patterns that delta encoding can exploit. All of these preprocessing steps are perfectly lossless — the original font data can be reconstructed exactly from the WOFF2 representation.

Compression Comparison: WOFF vs WOFF2

Real-world testing shows consistent and significant advantages for WOFF2 across font types. The following figures are representative measurements for popular fonts widely used in web design. Results can vary based on font complexity, glyph count, and the number and type of OpenType features included.

The decompression speed of WOFF2 is an important practical consideration. Brotli decompression is computationally more demanding than zlib decompression. However, Google's measurements showed that on typical mobile devices — even modest ones common in 2014-2016 — Brotli decompression of a font file takes only a few milliseconds. The network time saved by smaller files far outweighs the additional decompression time, even on low-powered mobile hardware.

On a 3G connection with a 1 Mbps download speed, saving 24 KB on a font file (as with Open Sans above) saves approximately 192 milliseconds of download time. The additional 2-3 ms of Brotli decompression time is negligible in comparison. On modern LTE and 5G connections, the decompression overhead is further dwarfed by other latency factors.

Standardization and Browser Adoption

The WOFF2 specification was developed within the W3C WebFonts Working Group. Google submitted the initial draft in 2014, with the specification authored by Tal Leming, Erik van Blokland, and David Kuettel, with significant technical contributions from the Google Fonts engineering team. The standardization process was relatively fast compared to other web standards, reflecting the clear technical superiority of the format and the absence of major competing proposals.

Internet Explorer never received WOFF2 support. For several years (2014-2018), web developers maintaining sites with significant IE traffic needed to serve both WOFF2 and WOFF 1.0 fallbacks. As of 2026, Internet Explorer's global usage has dropped below 0.5%, making WOFF2-only delivery safe for virtually all web projects. The remaining unsupported browsers are primarily legacy IE installations in specific enterprise environments.

WOFF2 in Practice Today

As of 2026, WOFF2 is the definitive web font format. Google Fonts has served WOFF2 by default since 2016, and major font services including Adobe Fonts, Fontshare, Bunny Fonts, and others all serve WOFF2 as the primary format. The question for most web developers is no longer "should I use WOFF2?" but "how do I use WOFF2 optimally?"

The combination of WOFF2's excellent compression and variable font technology represents the current frontier of efficient web font delivery. A single WOFF2 variable font file can contain an entire type family — all weights, widths, and optical sizes — in less space than several static WOFF2 files. This dramatically reduces HTTP requests and total transfer size for sites using rich typographic systems.

Future developments may include per-glyph subsetting (serving only the exact characters used on each page, computed at request time) and improved compression through machine learning-based predictions of font data patterns. But for the foreseeable future, WOFF2 will remain the standard — a format whose careful engineering in 2013-2014 continues to pay dividends in faster web experiences for billions of users.

Related History Pages

WOFF2 did not emerge in isolation — it is part of a longer story of web font development and format standardization. These related articles provide context for understanding WOFF2's place in the broader history of digital typography.