WOFF vs WOFF2: We Compared Six Fonts. Here’s How Much Smaller WOFF2 Was

WOFF2 is the starting format for a site targeting modern browsers; a WOFF fallback can cover an identified older-browser requirement. We compared both formats using six fonts, then repeated the comparison with Latin subsets to see how the file-size difference changed.

WOFF2 was 18.5% to 28.4% smaller in the twelve matched comparisons. The saving varied by font and subset. We measured encoded file bytes; page-load time was outside the study.

Contents

• What the two formats change
• What we measured
• Subsetting changed the question as well as the size
• How we made the comparison
• What the checks establish—and what they do not
• When a WOFF fallback is worth keeping
• Choose coverage before comparing bytes
• Method and evidence

What the two formats change

WOFF and WOFF2 package font data for the web. WOFF2 uses a different compression approach, including font-specific transformations and Brotli compression, as described in the W3C specification.

The formats preserve font information while changing how it is packaged and compressed. File size alone says nothing about the quality of a typeface or how accurately a particular browser renders it.

MDN’s current guidance uses WOFF2 for modern browsers and advises checking older-browser requirements before adding WOFF. We use that documentation for deployment advice; the measurements below cover files.

A file’s extension alone also does not establish permission to convert or serve it. Check the font license and use a licensed web-font build where appropriate.

What we measured

Original experiment · 18 Oct 2026 · Six static TrueType fonts.

WOFF2 was smaller in all twelve comparisons. The full-font reductions ranged from 21.2% to 28.4%; the Latin-subset reductions ranged from 18.5% to 25.8%.

For full Abel, WOFF occupied 15,808 bytes and WOFF2 occupied 11,616 bytes, a 26.5% reduction. For full Amiri, the corresponding files were 208,232 and 149,120 bytes, a 28.4% reduction.

The smallest relative reduction in the study was the Alice Latin subset: 28,604 bytes in WOFF and 23,308 bytes in WOFF2, or 18.5%. The absolute saving there was 5,296 bytes. Full Amiri saved 59,112 bytes. Percentage and byte savings tell related but different parts of the story.

The results table below records the first encode for each condition. The second encode produced the same hash in every condition. Percentages use the WOFF file as the denominator: (WOFF bytes minus WOFF2 bytes) divided by WOFF bytes.

Font	Scope	WOFF bytes	WOFF2 bytes	Reduction
abel	full	15,808	11,616	26.52%
abel	latin	11,780	8,740	25.81%
abeezee	full	24,884	19,348	22.25%
abeezee	latin	19,976	15,640	21.71%
alata	full	131,544	98,740	24.94%
alata	latin	41,176	32,648	20.71%
alice	full	58,360	46,000	21.18%
alice	latin	28,604	23,308	18.51%
amiri	full	208,232	149,120	28.39%
amiri	latin	22,364	17,968	19.66%
aboreto	full	26,704	20,992	21.39%
aboreto	latin	16,404	13,036	20.53%

Subsetting changed the question as well as the size

Full Amiri occupied 149,120 bytes in WOFF2; its requested Latin subset occupied 17,968 bytes. That is a large difference, but the smaller file no longer serves the same character-coverage purpose. It would be misleading to present the reduction as a free optimization for a site that needs Arabic.

Alata showed the same general distinction on a smaller scale: full WOFF2 was 98,740 bytes and the Latin subset was 32,648 bytes. Those figures show why it is worth examining coverage before focusing only on the difference between containers.

The valid format comparison holds the font input constant. Comparing a full WOFF file with a subsetted WOFF2 file would mix two changes and attribute too much to WOFF2.

For your site, decide what text the font must support before removing characters. That may include names, translated interfaces, user-submitted text, and future content, rather than only the text on today’s homepage. A tiny file that falls back unexpectedly for required text is not an equivalent replacement.

How we made the comparison

We selected Abel, ABeeZee, Alata, Alice, Amiri, and Aboreto from a pinned Google Fonts repository revision and retained each original font and OFL license. All six inputs are static TrueType fonts.

The six fonts form a convenience sample, not a representative survey. Full Amiri includes Arabic coverage; the Latin subset deliberately serves a narrower purpose.

For each font, we prepared two inputs: the full font and a subset requesting U+0020–007E and U+00A0–00FF. That request covers basic Latin text and Latin-1 characters, not everything a multilingual website might need. FontTools retained available requested characters and the glyphs its default subset rules required.

We saved each input once as a normalized uncompressed font, then encoded that identical input into WOFF and WOFF2. We repeated each encoding twice. That produced twelve matched format comparisons and 48 encoded files; repeat encodes are verification checks, not 48 independent font samples.

The run used FontTools 4.61.1 and Brotli 1.2.0 with timestamp recalculation disabled. The measured quantity was the saved file’s byte length, without an HTTP server, cache, or browser.

What the checks establish—and what they do not

Every saved output reopened successfully. Our encoding script compared each output’s character map, glyph order, and recorded outlines with its normalized source.

A separate verification script checked the saved byte counts and hashes, character maps, horizontal metrics, and glyph bounds. All 48 files passed those checks. Both scripts used FontTools, so this was separate verification code rather than a fully independent decoder.

These checks help catch missing characters, changed shapes detectable by those representations, and mismatched output files. They do not establish complete equivalence of layout behavior, hinting, vertical metrics, accessibility, or rendering in every application.

We did not test browser rendering, shaping, page-load time, LCP, HTTP transfer behavior, or real-world connection conditions. We also did not test variable fonts, CFF outlines, or commercial font builds. Do not extend these numbers to those cases as if we measured them.

WOFF2’s smaller byte count gives a reason to prefer it when compatible. It does not turn a 25% reduction in one font resource into a 25% faster page.

When a WOFF fallback is worth keeping

Start with the browsers you promise to support. If they support WOFF2, you can keep the font delivery setup simpler with a WOFF2 resource. If a required older browser needs WOFF, retain the appropriate fallback and test that environment.

MDN’s source-descriptor documentation explains how a font-face source list provides alternatives. A source list is not a requirement to send every format to every browser. Do not add together the WOFF and WOFF2 file sizes and call that the normal download cost of a correctly configured alternative-source rule.

For a regular 400-weight face that needs both formats, an illustrative source list is:

@font-face {
  font-family: "Example Sans";
  src: url("/fonts/example.woff2") format("woff2"),
       url("/fonts/example.woff") format("woff");
  font-weight: 400;
  font-style: normal;
}

Replace these example paths with your licensed files. If your supported browsers all accept WOFF2, omit the WOFF alternative. The browser selects an eligible source from the list; it does not normally download both formats for the same face.

Before release, inspect what the page actually requests and renders. Confirm the URL, content type, cross-origin configuration where relevant, and the font weight and style descriptors. Those are deployment checks still needed even when a conversion tool successfully produces a smaller file.

If you already have a working WOFF2 build, adding a WOFF copy without a compatibility requirement is unlikely to improve this decision. If you still serve WOFF, compare an equivalent WOFF2 build with the same characters and font settings.

Choose coverage before comparing bytes

Use the WOFF2 build that covers your site’s text. If you retain WOFF for a supported browser, build it from the same source and character set so that fallback delivery preserves the intended coverage.

Keep the complete licensed source font for future builds. A smaller subset is useful only while it includes the characters the site needs.

Method and evidence

Experiment EM-FONT-20261018-01 ran October 18, 2026. Source URLs and SHA-256 hashes, licenses, protocol, scripts, raw CSV, summaries, and saved test outputs are retained in the editorial evidence archive. This article states the reproducible method above; no public download has been released. Repository sources and FontTools documentation are linked below. Results apply only to these six static TrueType inputs and these settings.

Sources

• WOFF2 specification
• MDN web fonts guidance
• MDN font source descriptor
• FontTools subset documentation
• Google Fonts source repository