Convert TTF to WOFF2 Online (Raw Outlines to Brotli-Compressed Web Font)

Skipping Straight From an Installable Format to the Smallest Web Wrapper

A .ttf file stores every letter's outline as quadratic Bezier curves in a glyf table with zero compression applied anywhere in the file, which is exactly why it's the native format an operating system installs but a poor direct choice for serving over the web. WOFF2 is the second, newer generation of the W3C's web font wrapper effort, reaching Recommendation status on March 1, 2018, roughly six years after the original WOFF standard, with Google driving its development and providing the reference implementation still used by most conversion tools today. Converting directly from TTF to WOFF2 skips the older, intermediate WOFF format entirely and applies WOFF2's full compression pipeline straight to the raw, uncompressed TrueType data in one pass.

A reader typically holds a raw .ttf file because it came from a font foundry's default desktop release, an operating system's bundled typefaces, or an older toolchain that never generated a web-ready version. Since TTF carries no compression of any kind, converting straight to WOFF2 shows the largest possible size reduction of any font-format conversion available, because there's no existing compression layer being replaced, only raw table data being compressed for the first time.

What Changes Between Raw Outline Data and a Brotli-Compressed Stream

WOFF2 compresses the entire font as a single Brotli stream rather than compressing individual tables separately the way WOFF's zlib approach does, which lets Brotli find and exploit repeated patterns across table boundaries that a per-table method simply can't see. On top of that, WOFF2 applies a specific preprocessing transform to the glyf and loca tables, based on the MicroType Express format Monotype originally built for a different purpose, which reorganizes glyph outline data using lengths instead of offsets and variable-length number encoding before Brotli ever touches it, making that data measurably more compressible than its original layout.

None of this changes a single glyph's actual shape, curve point, or hinting instruction; every part of this pipeline, from the glyf/loca transform through Brotli compression, is fully reversible, which is why decompressing a WOFF2 file reconstructs the exact original TrueType data. A concrete, measured example makes the combined effect clear: Roboto Regular runs about 168 KB as a raw TTF and roughly 53 KB once converted directly to WOFF2, a reduction of nearly 68 percent from the uncompressed original, achieved with zero loss of visual fidelity.

The W3C's WOFF2 specification actually defines a third transformable table beyond glyf and loca: hmtx, the table holding each glyph's horizontal metrics, can also be preprocessed before Brotli compression when its per-glyph values are regular enough to benefit, though many encoders skip this optional step since the size gain is small compared to the glyf/loca transform. The specification also defines what it calls a "null transform," version 3, for the glyf and loca tables, meaning the original untransformed table data was passed straight into the Brotli stream without any reorganization at all, an option encoders fall back on for fonts whose outline data doesn't benefit from the standard transform.

The Real Trade-offs of Going Directly to the Newest Web Format

• Gain — the largest size reduction of any font conversion: since raw TTF carries zero compression, going straight to Brotli-compressed WOFF2 shows a bigger drop than converting an already-compressed WOFF file would.
• Gain — a single conversion step instead of two: there's no technical requirement to generate an intermediate WOFF file first; modern tools apply WOFF2's full pipeline directly to raw sfnt data.
• Lose — support in Internet Explorer, in any version: IE never implemented WOFF2, a real gap if any meaningful share of traffic still uses that retired browser.
• Lose — direct desktop installability: like WOFF, WOFF2 is a web-only wrapper; the resulting file can't be installed as a system font without converting back.
• Unchanged — every outline curve and hinting instruction: the entire transform-plus-Brotli pipeline is lossless, so nothing about how the font actually renders is altered.
• Risk — no automatic WOFF fallback: converting directly to WOFF2 only, without also generating a WOFF file, leaves no fallback for the small remaining population on pre-2018 browser versions.

Exactly Which Browsers Read a Direct TTF-to-WOFF2 Result

The resulting WOFF2 file's compatibility is identical no matter whether it was converted directly from TTF or by way of an intermediate WOFF, since the format itself doesn't record its conversion history. Chrome added WOFF2 support first, in Chrome 36 in 2014; Firefox followed in Firefox 39 in 2015; Microsoft's Edge added support at version 14 in 2016; iOS Safari added it at version 10, also in 2016; and desktop Safari on macOS was the last major holdout, only adding support in Safari 12 in 2018, four full years after Chrome.

Internet Explorer never supported WOFF2 at all, in any version, which is the one gap a reader converting straight from a raw TTF needs to plan around if any of their traffic still runs that retired browser. For every other currently maintained browser, the file works natively, and current usage-share data puts global WOFF2 support in the high 90s percentage-wise, meaning the standard practice of also generating a WOFF fallback exists to cover a genuinely small, shrinking tail rather than any meaningful share of visitors today.

Why a Font That Worked Locally Breaks the Moment It's Uploaded

Build-tool and bundler discussion threads document a specific, recurring failure: a WOFF2 file converts correctly, previews fine on a local machine, then throws an "OTS parsing error: invalid sfntVersion" or "Failed to decode downloaded font" message the moment it's served from a live server or a bundled build. Investigation into these reports, including issues logged against webpack, Vite, and several CSS framework projects, traces the cause to the file getting corrupted in transit through a build or deployment pipeline that treats the binary font file as text, most often because a loader or CDN configuration wasn't set to handle it as raw binary data; the fix is configuring the specific build tool or server to pass the file through untouched as binary rather than reprocessing it as text.

A second, separate cause of the same visible error is a server simply not being configured with the correct MIME type for .woff2 files at all, since many web servers, nginx included, ship with no default font MIME types out of the box; adding an explicit font/woff2 mapping to the server's configuration resolves this specific version of the failure, distinct from the build-tool corruption case above.

Chromium and Firefox both run every downloaded font, WOFF2 included, through the OpenType Sanitizer (OTS) library before allowing it to render, and a font that fails that check produces console messages like "OTS parsing error: invalid sfntVersion" or "OTS parsing error: glyf: Failed to parse glyph," both signs the file arrived truncated or altered somewhere in the delivery chain rather than a problem with the conversion itself. Running the same OTS check locally, using the sanitizer's own command-line build, reproduces the identical error message outside the browser, which font-engineering forums recommend specifically as a way to confirm whether a given file is actually corrupted before spending time debugging server or CDN configuration instead.

Uncompressed Desktop Font Weighed Against Its Brotli-Compressed Version

Questions About Converting Straight to the Newest Web Format

Do I need to convert to WOFF first before making a WOFF2 file?
No. Modern conversion tools apply WOFF2's full Brotli-plus-transform pipeline directly to raw TTF data in a single step; there's no technical requirement to generate an intermediate WOFF file.

How much smaller will my font actually get?
Often 60 to 70 percent smaller than the raw TTF, since there's no prior compression layer being replaced. Roboto Regular, for example, drops from 168 KB to roughly 53 KB.

Why does my converted font fail after I upload it?
Two common causes: a build pipeline or CDN mishandling the binary file as text, corrupting it, or a server missing the correct font/woff2 MIME type configuration entirely. Both produce the same "failed to decode" browser error.

Should I still generate a WOFF fallback alongside WOFF2?
Yes, as standard practice, since Internet Explorer never supported WOFF2 at all and a small population of older browser versions predates its 2014-2018 rollout window.

What does an "OTS parsing error" in my browser console actually mean?
It means Chromium or Firefox's built-in OpenType Sanitizer rejected the font file as malformed or corrupted before attempting to render it, most often because the file was altered in transit by a build tool, CDN, or misconfigured server rather than because of anything wrong with the original conversion.