What Is a WOFF2 File? The Format Google Built to Replace WOFF

The Format Google Built to Replace an Already-Compressed Wrapper

WOFF2 is the second generation of the W3C's web font wrapper effort, reaching Recommendation status on March 1, 2018, roughly six years after the original WOFF standard was finalized in 2012. Where the original WOFF format came out of a collaboration between Mozilla engineer Jonathan Kew and type designers Erik van Blokland and Tal Leming, WOFF2's development was led by Google, which also built and maintains the reference compression library most conversion tools rely on today. Like its predecessor, WOFF2 is a wrapper format, not a new way of drawing letters: it holds the same TrueType or OpenType sfnt-based outline data WOFF does, just compressed and organized differently.

A reader encountering a .woff2 file is looking at whatever font a website chose as its primary web format, since this is now the standard first choice for essentially every modern site, with WOFF kept only as a fallback for the shrinking population of browsers old enough to predate WOFF2's rollout. Google Fonts, one of the most widely used web font delivery services, serves WOFF2 by default to any browser that supports it, falling back to WOFF or TTF automatically based on the requesting browser's own capabilities, which is part of why WOFF2 has become the format most readers actually encounter without ever choosing it directly.

What's Actually Inside a .woff2 File

The entire practical difference between WOFF and WOFF2 comes down to one specific engineering swap plus one additional transform: WOFF2 replaces WOFF's per-table zlib compression with Brotli, applied to the whole font as a single stream rather than table by table, which lets the compressor find and exploit repeated patterns across table boundaries that a per-table approach can't see. On top of that, WOFF2 applies a preprocessing transform, based on the MicroType Express format Monotype originally developed, specifically to the glyf and loca tables, reorganizing outline and index data using lengths instead of offsets and variable-length number encoding before Brotli compression ever runs, making that data measurably more compressible than its original layout.

Both the transform and the Brotli compression are fully reversible, meaning decompressing a WOFF2 file back to plain sfnt data reconstructs the exact original outline curves and hinting instructions with zero loss; nothing about how a letter actually looks or renders is affected by any part of this compression pipeline.

The WOFF2 specification defines a third optional transform beyond glyf and loca: the hmtx table, which stores each glyph's horizontal metrics, can also be preprocessed before Brotli compression when doing so produces a measurable size benefit, though many encoders skip this specific step since its typical gain is smaller than what the glyf/loca transform already provides. Most conversion tools also default to Brotli's own highest quality setting, level 11 on Brotli's 0-to-11 scale, in the reference woff2_compress implementation, favoring the smallest possible file over faster encoding speed, since compression happens once during conversion while every visitor afterward benefits from the smaller download.

Brotli itself predates its use inside WOFF2: Google originally released it in 2013 as a general-purpose compression algorithm for web content, and the IETF standardized it separately as RFC 7932 in 2016, meaning the same underlying compression method that shrinks a WOFF2 font file is also used by browsers and servers to compress ordinary HTTP responses like HTML, CSS, and JavaScript through the Content-Encoding: br header.

Where This Format Has Become the Default Rather Than an Option

• Gain — a documented 30-40% smaller file than WOFF: Brotli compression combined with the glyf/loca transform consistently outperforms WOFF's older zlib approach on real fonts.
• Gain — near-universal current browser support: every currently maintained browser reads WOFF2 natively, with global usage-share support commonly reported around 97 percent.
• Lose — support in Internet Explorer, in any version: IE never implemented WOFF2 at all, relevant only for sites confirmed to still have meaningful IE traffic.
• Unchanged — every glyph curve and hinting instruction: the compression is fully lossless; converting back to TTF or OTF reconstructs the original outline data exactly.
• Lose — direct desktop installability: like WOFF, this remains a web-only wrapper; converting to TTF or OTF is required to install the font as a system font.
• Gain — a real, measurable page-speed effect: the smaller download size directly reduces how long a browser waits before rendering text in a custom font.

The Real Browser Rollout Timeline, Version by Version

WOFF2 support rolled out over several years rather than all at once: Chrome added it first, in Chrome 36, released in 2014, with Opera following at version 23 around the same time. Firefox added support in Firefox 39 in 2015, iOS Safari picked it up at version 10 in 2016, Microsoft's Edge added support starting at version 14 also in 2016, and desktop Safari on macOS was the last major holdout, not adding support until Safari 12 in 2018, a full four years after Chrome.

Internet Explorer never supported WOFF2 in any version at all, including IE11, which given IE's retirement in June 2022 means there's no realistic current browser gap to plan around beyond that already-dead browser. Global browser usage-share tracking commonly puts current WOFF2 support in the high 90s percentage-wise, which is exactly why the standard @font-face practice of listing WOFF2 first and WOFF second exists to cover a genuinely small, shrinking tail rather than any meaningful share of general visitors today.

The Support Threads Where This Format Still Trips People Up

A recurring, well-documented issue across build-tool and CMS bug trackers involves a WOFF2 file that converts and previews correctly locally, then throws an "OTS parsing error: invalid sfntVersion" or "Failed to decode downloaded font" message once deployed live. Investigation into these reports, including issues logged against webpack, Vite, and several theme frameworks, traces the cause to the binary font file being corrupted somewhere in a build or deployment pipeline that mishandled it as text rather than passing it through untouched as raw binary data; the fix is configuring the specific build tool or loader to treat the file as binary throughout.

A second, unrelated cause of the identical error message is a web server simply missing the correct MIME type configuration for .woff2 files, since servers like nginx ship with no default font MIME types out of the box; adding an explicit font/woff2 mapping to the server configuration resolves this specific version of the failure, distinct from the build-pipeline corruption case above.

Both of those failure modes trace back to the same underlying gatekeeper: Chromium and Firefox each run every downloaded font through the OpenType Sanitizer (OTS) library before allowing it anywhere near a rendering engine, and OTS is specifically designed to reject anything it can't confirm is safely well-formed, logging a distinct message for each kind of problem it finds, such as "OTS parsing error: invalid sfntVersion" for a corrupted header or "OTS parsing error: glyf: Failed to parse glyph" for damaged outline data. Font-engineering forums commonly recommend running a suspect file through the standalone OTS command-line tool directly, which reproduces the identical rejection message a browser would show, as a first diagnostic step before assuming the problem lies in server configuration or CSS.

This Format Set Directly Against the Wrapper It Replaced

Frequently Asked Questions About the Current Web Font Standard

Who actually built the WOFF2 format?
Google led its development, providing the Brotli compression algorithm and the reference implementation, and the W3C standardized it as a Recommendation in 2018.

How much smaller is WOFF2 than the older WOFF format?
Current comparisons consistently show a 30-40% reduction, driven by Brotli replacing zlib and the glyf/loca table transform making outline data more compressible before compression.

Do all browsers actually support WOFF2?
Nearly all current ones. Every major browser has supported it since at least 2018, with global usage-share support around 97%; only Internet Explorer, now retired, never supported it.

Can I install a WOFF2 file directly on my computer?
No. It's a web-delivery wrapper only; converting it to TTF or OTF first is required before an operating system will install it as a usable font.

Is the Brotli compression inside WOFF2 the same Brotli used elsewhere on the web?
Yes. Google released Brotli in 2013 as a general-purpose algorithm, later standardized separately as RFC 7932 in 2016, and the same compression method also shrinks ordinary HTTP responses like HTML, CSS, and JavaScript through the Content-Encoding: br header, not just font files.

What does an "OTS parsing error" actually mean when I see it?
It means Chromium or Firefox's built-in OpenType Sanitizer rejected the font as malformed before allowing it to render, logging a specific message describing what it found broken, such as an invalid header tag or a glyph it couldn't parse; running the file through the standalone OTS tool reproduces the same diagnostic outside the browser.