Made Good Designs

WOFF2 vs WOFF: What to Serve in 2026

·

Editorial Team
woff2 vs woff — guide and examples

WOFF2 vs WOFF: What to Serve in 2026

In the WOFF2 vs WOFF decision, there is a clear winner: serve WOFF2 to everyone, and treat WOFF as an optional fallback you can probably drop entirely. WOFF2 compresses fonts about 30% smaller than WOFF using Brotli, and it has had universal browser support for years. This guide explains the real differences, when (if ever) WOFF still matters, and the exact @font-face setup to ship.

Both are wrappers around the same outlines, not different typefaces — for the full picture of where they sit among TTF, OTF, and the rest, see our guide to font file formats.

What WOFF and WOFF2 Actually Are

Neither is a font in the design sense. WOFF (Web Open Font Format, 2010) takes a TTF or OTF, compresses its tables with zlib (gzip-class), and adds metadata for licensing — a web-specific container that foundries were comfortable serving. WOFF2 (2018) is the same idea with a better engine: it swaps zlib for Brotli and applies font-aware preprocessing, squeezing files significantly harder.

So the question is never “which renders better” — they render identically because the glyph outlines are the same. It is purely about file size and support, and on both counts WOFF2 has pulled decisively ahead.

It helps to remember why these formats exist at all. Browsers will technically load a raw TTF or OTF through @font-face, but those files are uncompressed and were never licensed with web delivery in mind. WOFF solved both problems at once: it shrank the file and gave foundries a wrapper they were willing to sell for embedding. WOFF2 then kept that same licensing posture and simply made the compression dramatically better. Nothing about your CSS, your fallbacks, or your rendering changes between them — only the bytes on the wire.

The Core Differences

WOFF WOFF2
Released 2010 2018
Compression zlib (gzip-class) Brotli + font preprocessing
Typical size vs raw TTF ~40% smaller ~50%+ smaller
Size vs each other baseline ~30% smaller than WOFF
Browser support IE9+ and all modern All modern browsers (2016+)
Role in 2026 Optional legacy fallback The default — serve this

The headline number worth remembering: WOFF2 is roughly 30% smaller than WOFF. On a render-blocking resource like a web font, that directly improves perceived load time and Core Web Vitals.

Browser Support in 2026

WOFF2 is supported by every browser anyone realistically serves today: Chrome, Edge, Firefox, Safari (desktop and iOS), Samsung Internet, and Opera have all supported it since roughly 2016. The browsers that lack WOFF2 — Internet Explorer 11 and a handful of ancient mobile builds — are statistically a rounding error and, in IE’s case, fully retired by Microsoft.

This is why the calculus has shifted. A few years ago WOFF was the safe baseline. In 2026, WOFF2 is the safe baseline, and WOFF is the thing you keep only if you have a documented obligation to support a legacy browser.

How Much Does WOFF2 Actually Save?

The savings are easy to underestimate until you watch them on a real font. A typical Latin text family weighs roughly 100–160 KB as a raw TTF. The same font compresses to around 60–90 KB as WOFF, and down to roughly 40–60 KB as WOFF2. Multiply that by the four or five weights a brand commonly loads and the difference becomes hundreds of kilobytes on first paint — bytes that block text from rendering until they arrive.

Those bytes also land on the critical rendering path, so the impact is felt in Largest Contentful Paint and in how quickly readable text appears. Pairing WOFF2 with font-display: swap and a preload on your primary face gives you the fastest practical font experience without any rendering compromise. The compression is genuinely free performance — there is no quality or compatibility cost to claim it on a modern site.

What to Serve: The @font-face Order

The src descriptor lists formats in order of preference, and the browser uses the first one it understands. Put WOFF2 first:

@font-face {
  font-family: "Brand Sans";
  src: url("/fonts/brandsans.woff2") format("woff2"),
       url("/fonts/brandsans.woff")  format("woff");
  font-weight: 400;
  font-display: swap;
}

Modern browsers grab the WOFF2 and never download the WOFF. If you have no legacy obligation, you can drop the second line entirely and ship WOFF2 alone — simpler, and one fewer file to host. Either way, this is the same @font-face pattern covered in adding custom fonts to any website.

Do You Still Need WOFF at All?

For the overwhelming majority of projects, no. Keep WOFF only if one of these is true:

  • You have a contractual requirement to support Internet Explorer 11 or an equivalent legacy browser.
  • Your analytics show a non-trivial share of traffic from devices without WOFF2.
  • You serve a market or kiosk environment locked to old software.

Otherwise, dropping WOFF removes a file from every page load with zero practical downside. Variable fonts make this even clearer: they are almost always delivered as WOFF2, so a variable font setup is typically WOFF2-only by default.

If you are nervous about cutting WOFF, the honest test is your own analytics, not a general statistic. Pull the browser breakdown for the last 90 days and look for any meaningful share without WOFF2 support. For nearly every site that number rounds to zero, and even those rare visitors degrade gracefully to a system font rather than seeing broken text. The risk of WOFF2-only is almost always smaller than the recurring cost of shipping and maintaining a second set of files no one downloads.

Getting WOFF2 Files

If your foundry gives you only desktop TTF/OTF, generate WOFF2 yourself: the Font Squirrel Webfont Generator (web UI), Google’s woff2_compress, or fontTools (pip install fonttools[woff]) all produce it. Subset to the characters and language you actually use while you convert — that often saves more bytes than the WOFF-to-WOFF2 jump itself. And confirm the license permits web embedding before you deploy.

Frequently Asked Questions

Is WOFF2 better than WOFF?

Yes for the web. WOFF2 uses Brotli compression and is about 30% smaller than WOFF while rendering identically, since both wrap the same outlines. With universal modern-browser support, WOFF2 is the default to serve in 2026; WOFF only remains useful as a fallback for legacy browsers.

Do I still need to include WOFF as a fallback?

Usually not. Every current browser supports WOFF2, so WOFF only matters if you must support Internet Explorer 11 or similar legacy environments. For typical sites you can serve WOFF2 alone, removing an extra file with no practical downside.

What’s the difference between WOFF and WOFF2 compression?

WOFF uses zlib (gzip-class) compression, while WOFF2 uses Brotli plus font-specific preprocessing. The result is that WOFF2 files are roughly 30% smaller than the equivalent WOFF, which speeds up font loading and improves Core Web Vitals on render-blocking font requests.

How do I set the @font-face src order for WOFF2 and WOFF?

List WOFF2 first, then WOFF: src: url(“font.woff2”) format(“woff2”), url(“font.woff”) format(“woff”). Browsers pick the first format they support, so modern browsers download only the WOFF2 and ignore the WOFF fallback entirely.

Will serving only WOFF2 break older browsers?

Only browsers without WOFF2 support, mainly Internet Explorer 11 and a few very old mobile builds, which are effectively retired. For those rare cases, text falls back to a system font rather than failing. Check your analytics; for nearly all sites, WOFF2-only is safe.

Keep Reading