Reference Formats
WOFF2
WOFF2 is the successor to WOFF, a W3C-standardized web font container that uses Google's Brotli compression and table-specific transforms to shrink font files substantially further than WOFF 1.0.
Extension
.woff2
Full name
Web Open Font Format 2.0
Introduced
First public working draft circa 2014-2015; became a W3C Recommendation in March 2018
Vendor
W3C (reference implementation and Brotli compression algorithm by Google)
What is inside the container
WOFF2 keeps a similar container concept to WOFF (header, table directory, font table data) but replaces per-table zlib compression with a single Brotli-compressed stream covering the whole font, and applies optional preprocessing transforms (e.g. glyf/loca table reformatting) before compression to increase redundancy. It also uses a more compact table directory encoding than WOFF 1.0, further reducing overhead, and still supports the same optional XML metadata and private data blocks.
How to open it
For archives
Treat WOFF2 strictly as a build-time web delivery derivative, never as the archival master — keep the source OTF/TTF (or foundry master) as the preservation copy and regenerate WOFF2 automatically whenever the source font or its subsetting requirements change. Because WOFF2 is now supported by essentially all current browsers, a DAM's web-delivery pipeline should default to producing WOFF2 first and only add a WOFF fallback rendition if legacy-browser support is a stated requirement.
WOFF2 emerged because WOFF 1.0’s zlib-based compression left real savings on the table. Google engineers, working within the W3C Web Fonts Working Group, proposed a successor built around Brotli, a general-purpose compression algorithm Google developed specifically to beat gzip and zlib on web content. WOFF2 also introduced preprocessing transforms that reorganize certain OpenType tables (notably glyph outline data) before compression, exploiting redundancy that raw sfnt table layout hides. The result, reported by Google’s own benchmarking and echoed across font tooling documentation, is meaningfully smaller files than equivalent WOFF or raw OTF fonts. The W3C published WOFF2 as a full Recommendation in March 2018, with Google providing the reference codec that browser vendors adopted directly.
Browser support for WOFF2 is now near-universal among actively maintained browsers (Chrome, Firefox, Safari, Edge, and their mobile counterparts have supported it for years), while Internet Explorer never implemented it — a distinction any DAM-driven web build has to account for when deciding which fallback formats to keep generating.
| Browser | Minimum version |
|---|---|
| Chrome | 36+ |
| Firefox | 39+ |
| Safari | 12+ (partial support in 10–11) |
| Edge | 14+ |
| Internet Explorer | Not supported |
For DAM practice, WOFF2 is the default target rendition for any typeface asset destined for the web: it is smaller, it decodes faster in the browser, and it is what modern @font-face stacks list first. As with WOFF, a WOFF2 file still carries the underlying font’s licensing terms — compressing and reformatting the data does not waive the foundry’s embedding license — so DAM systems that auto-generate WOFF2 from a master font on ingest or build should propagate the same license metadata (permitted domains, subsetting rights, foundry attribution) to the generated file’s record, not just to the source.
WOFF2’s arrival, together with WOFF’s earlier displacement of EOT and raw TTF/OTF linking, effectively closed the era of maintaining three or four separate web font formats per typeface. Most current web builds need only WOFF2, with WOFF kept solely as an older-browser fallback — a simplification that reduces the number of font renditions a DAM has to track, convert, and re-license per typeface.
Frequently asked
How much smaller is WOFF2 than WOFF in practice?
WOFF2's Brotli compression and table transforms typically produce noticeably smaller files than WOFF 1.0's zlib compression on the same source font, though exact savings vary by font content and are best measured per-asset rather than assumed as a fixed percentage.
Does WOFF2 need a WOFF fallback in a DAM's web build pipeline?
Only if the site must support browsers that predate WOFF2 support (notably Internet Explorer, which never added it, and older Safari/Firefox/Edge versions) — otherwise WOFF2 alone is sufficient for current browsers.
Can WOFF2 be converted back to the original desktop font?
Technically yes — tools like Google's woff2_decompress utility or the fontTools library can decompress a WOFF2 file back into a standard TTF/OTF sfnt font. But the recovered file is not identical to the original desktop font. WOFF2 files served on the web are frequently subset, containing only the glyphs a specific page actually uses, so decompression yields that reduced glyph set, not the full character set. Hinting data and some OpenType features can also be trimmed during subsetting, so treat a decompressed WOFF2 as a partial recovery rather than a faithful restoration of the source font.
Who maintains the WOFF2 specification and reference codec?
The World Wide Web Consortium (W3C) owns the WOFF2 specification: its WebFonts Working Group developed it, and it reached Recommendation status — W3C's formal seal for a finished web standard — in March 2018. Implementation is a separate track. Google authored the Brotli compression algorithm used inside WOFF2 and maintains the reference encoder/decoder — the open-source woff2 library on GitHub, plus command-line tools like woff2_compress and woff2_decompress — that most font tools and browsers build on.
Should a DAM store the WOFF2 file as the canonical font asset?
No. WOFF2 is a web-delivery derivative — one output among several (WOFF2, WOFF, sometimes subsetted variants) generated for browser delivery — not the archival source. The canonical asset a DAM should retain is the original desktop font format, typically TTF or OTF (or the vendor's master/source file), from which all web variants are generated. Because WOFF2 can be regenerated at any time from that master using standard tooling, storing only the WOFF2 risks losing full glyph coverage, hinting data, and licensing metadata tied to the original file.
What DAM metadata matters most for a WOFF2 rendition?
Which master font it was generated from, the subsetting applied (character ranges included), the web-embedding license terms inherited from that master, and the build/generation date so stale renditions can be detected and regenerated.
Does subsetting affect what's inside a WOFF2 container?
Yes — WOFF2s are frequently generated with only a subset of glyphs (e.g. Latin characters only) to reduce size further; a DAM should record the subsetting scope so the rendition isn't mistaken for the complete character set of the source font.
Is WOFF2 an open format free of licensing restrictions on the container itself?
Yes, but only for the container. The WOFF2 wrapper format and the Brotli compression algorithm inside it are open specifications, free of royalties, and implementable without a license. That openness, however, applies to the packaging mechanism only — not to the font it carries. A WOFF2 file built from a commercial or restrictively licensed typeface still carries that foundry's original license terms; wrapping a font in an open container doesn't unlock or override the embedding rights the foundry granted.
Sources
- WOFF 2.0 became a W3C Recommendation in March 2018, with Google providing the reference implementation. checked 2026-08-07 — W3C Press Release
- WOFF2 specification requires the CompressedFontData stream to be compressed with the Brotli algorithm, developed by Jyrki Alakuijala and Zoltan Szabadka. checked 2026-08-07 — W3C WOFF File Format 2.0 spec
- WOFF2 browser support: Chrome 36+, Firefox 39+, Safari 12+ (partial 10-11), Edge 14+, no Internet Explorer support. checked 2026-08-07 — caniuse.com