Convert WOFF to WOFF2 Online (Zlib Rewrapped as Brotli)

Recompressing the Same Wrapped Font With a Newer Algorithm

A WOFF file already wraps sfnt-based outline data, compressed individually per table with zlib, following the format the W3C standardized in 2012. WOFF2, reaching its own W3C Recommendation in 2018 with Google driving development and providing the reference implementation, wraps that same underlying outline data using a fundamentally different approach: Brotli compression applied to the whole font as a single stream, plus a preprocessing transform on the glyf and loca tables based on Monotype's MicroType Express format, which reorganizes outline data using lengths instead of offsets before Brotli ever runs. Converting an existing WOFF file to WOFF2 means fully reversing WOFF's zlib compression to recover the plain sfnt tables, then running that recovered data through this entirely different transform-and-Brotli pipeline.

A reader typically requests this specific conversion because they built a website some years ago using WOFF, back when it was the only broadly supported web font wrapper, and are now upgrading an existing font library to take advantage of stronger compression without touching how the site's typography actually looks. This particular direction, WOFF to WOFF2 rather than TTF to WOFF2, is common specifically among site owners who no longer have access to the original raw font files, having only the already-deployed WOFF version left in their asset library.

What Actually Happens When Zlib Output Gets Rebuilt as Brotli Output

Because WOFF and WOFF2 use unrelated compression algorithms rather than variations on the same one, there's no way to transform compressed WOFF bytes directly into compressed WOFF2 bytes; the conversion has to fully decompress back to the original, unwrapped sfnt table data as an intermediate step, discarding WOFF's zlib output entirely, before WOFF2's own pipeline can begin. Since this decompression step is fully lossless, the recovered sfnt data going into the WOFF2 pipeline is identical to what would come from converting straight from a raw TTF, meaning the size reduction achieved going from WOFF to WOFF2 reflects the genuine algorithmic advantage of Brotli plus the glyf/loca transform over zlib, not any artifact of the conversion path.

Current benchmark comparisons consistently show WOFF2 files running 30 to 40 percent smaller than the equivalent WOFF version of the same font; Roboto Regular, for example, runs about 85 KB as gzip/zlib-compressed WOFF and roughly 53 KB as Brotli-compressed WOFF2, a real, measured 38 percent reduction between the two web formats on an identical typeface.

This improvement scales with how many separate font files a page loads, which is worth accounting for directly rather than treating as an abstract percentage: a page loading four weights of the same family, say regular, bold, italic, and bold-italic, sees that 30 to 40 percent reduction applied to every one of those four files, meaning the total payload difference between an all-WOFF font stack and an all-WOFF2 one is considerably larger in absolute kilobytes than converting a single file might suggest.

The WOFF2 specification also defines an optional transform for the hmtx table, which stores each glyph's horizontal metrics, alongside the better-known glyf/loca transform; most conversion tools default to Brotli's own maximum quality setting, quality level 11 in the reference woff2_compress implementation, favoring the smallest possible output size over faster compression speed, since the compression step happens once during conversion while the resulting smaller file gets downloaded by every visitor afterward.

What a Direct Format Upgrade Gains Without Touching a Single Glyph

• Gain — a documented 30-40% smaller file than WOFF: Brotli's whole-font compression plus the glyf/loca transform consistently outperforms WOFF's per-table zlib approach.
• Gain — near-universal current browser support: every currently maintained browser reads WOFF2 natively, with global support commonly reported around 97 percent.
• Unchanged — every glyph outline and hinting instruction: the entire pipeline, decompression through recompression, is lossless, so nothing about how the font renders changes.
• Lose — support in Internet Explorer, in any version: IE never implemented WOFF2, relevant only for sites still needing to support that now-retired browser.
• Gain — reduced font-loading time on font-heavy pages: pages using several weights (regular, bold, italic) see a proportionally larger total savings, since the reduction applies to every file.
• Lose — nothing structural by keeping the old WOFF file too: there's no downside to retaining the original WOFF alongside the new WOFF2 as a fallback line in CSS.

The Version Cutoffs That Decide Whether This Upgrade Is Even Needed

WOFF2 support rolled out over several years: Chrome added it first, in Chrome 36 in 2014, Firefox followed in Firefox 39 in 2015, Edge added support at version 14 in 2016, iOS Safari picked it up at version 10 also in 2016, and desktop Safari on macOS was the last major holdout, not supporting it until Safari 12 in 2018. Internet Explorer never added WOFF2 support in any version, a gap that matters only for sites confirmed to still have meaningful IE traffic, given IE's retirement in June 2022.

For any site whose analytics show traffic concentrated on browser versions from the last several years, this upgrade carries essentially no compatibility risk, since the same browsers that already read the original WOFF file also read WOFF2, just with the added benefit of a smaller download; the standard practice of listing WOFF2 first and keeping WOFF second as a fallback exists specifically to cover the narrow, shrinking population still on pre-2018 browser versions.

Why Some Sites Still Haven't Made This Switch

Page-speed audit tools and Core Web Vitals-focused reports commonly flag a site still serving only WOFF fonts as an easy optimization opportunity, specifically because the WOFF2 alternative offers a real, measurable size reduction with essentially no added browser-compatibility risk for a modern audience; the reported fix in these cases is generating WOFF2 versions of the existing font files and updating the CSS @font-face src list to put WOFF2 first, keeping the original WOFF line as a fallback rather than removing it.

A less common complaint involves a site that generated WOFF2 versions correctly but never updated the CSS source order, leaving WOFF2 listed after WOFF in the @font-face rule; browsers generally load the first supported format they encounter in that list, so a WOFF2 file listed second never actually gets used by any browser capable of loading the WOFF line that comes before it, silently wasting the entire benefit of having generated it in the first place.

A third pattern involves a CMS or page-builder plugin that auto-generates web font files on upload but was configured or coded years ago, before WOFF2 was standard, and never updated to output anything beyond WOFF; sites built on that kind of dated tooling need either a manual conversion step outside the platform or a plugin update, since the platform itself simply never learned to produce the newer format on its own.

A fourth, more technical report shows up in browser console logs as an "OTS parsing error" on a freshly generated WOFF2 file that worked fine as WOFF; since Chromium and Firefox both run every downloaded font through the OpenType Sanitizer before rendering it, this specific error means the conversion tool produced a malformed WOFF2 table directory or Brotli stream, which font-engineering forums recommend diagnosing by running the file through the standalone OTS command-line checker before assuming the problem lies anywhere else in the deployment pipeline.

One Font, Two Compression Generations, Measured Directly

Questions About Upgrading an Existing Web Font Library

How much smaller will my existing WOFF fonts get?
Typically 30 to 40 percent smaller, based on current benchmark comparisons; a Roboto Regular file, for example, drops from about 85 KB as WOFF to roughly 53 KB as WOFF2.

Should I delete my old WOFF files after converting?
No, keep them as a fallback. List WOFF2 first in your CSS @font-face rule so modern browsers grab the smaller file, with WOFF second for the small remaining population on older browser versions.

Why isn't my new WOFF2 file actually being used?
Check your CSS source order. If WOFF2 is listed after WOFF in the @font-face src list, browsers that already support WOFF will load that file first and never reach the WOFF2 line.

Will this conversion change how my font renders?
No. Both WOFF's zlib decompression and WOFF2's Brotli recompression are fully lossless; every glyph outline and hinting instruction stays identical.

My new WOFF2 file throws an "OTS parsing error." What does that mean?
It means Chromium or Firefox's built-in OpenType Sanitizer rejected the file as malformed before rendering it, which usually points to a broken table directory or Brotli stream produced during conversion; running the file through the standalone OTS checker helps confirm the problem before looking elsewhere in your deployment setup.