Convert TTF to WOFF2 Online

How to Convert TTF to WOFF2 Online

1. Upload Your TTF File: Drag and drop or click "+ Add Files" to load one or more .ttf files. Batch conversion is supported — drop an entire font family (Regular, Bold, Italic, Bold Italic) in one pass. Files stay in your browser session.
2. Confirm WOFF2 as the Output: The output is locked to WOFF2 on this page — no codec or quality slider needed. WOFF2 uses Brotli compression on the original glyph data, so the conversion is lossless: every glyph, kerning pair, OpenType feature, and variable-font axis from the source TTF carries over.
3. Review the File List (Optional): Reorder files, remove any you don't want to convert, or add more TTFs to the batch. If you only need a Latin subset for a website, subset the TTF first (pyftsubset or a similar tool) to strip unused glyphs before converting.
4. Convert and Download: Click "Convert." Each .woff2 downloads individually, or grab the whole batch as a ZIP. No sign-up, no watermark, no email required, and nothing is uploaded to a server — parsing happens locally with a lazy-loaded opentype.js worker.

Why Convert TTF to WOFF2?

TTF (TrueType Font) is the desktop standard developed by Apple and Microsoft in the late 1980s — every operating system installs and renders it natively. But TTF files are uncompressed: a typical Latin-only TTF runs 80–250 KB, and a multilingual family can push past 1 MB per weight. WOFF2 (Web Open Font Format 2.0) wraps the same glyph data in a Brotli-compressed container designed specifically for web delivery. It became a W3C Recommendation in March 2018 (latest revision August 2024) and is the format the W3C, Google Fonts, and every major CDN now ship as the default format("woff2") entry in @font-face rules.

• Smaller payloads, faster sites — WOFF2 typically reduces TTF size by 50% on average (35–65% range depending on glyph count and outline type) thanks to Brotli plus a content-aware preprocessing step that reorders the glyph tables before compression. A 200 KB Inter Regular TTF lands around 95 KB as WOFF2 (52%); a 1.2 MB Noto Sans CJK weight shrinks past 60% in many cases. Smaller fonts mean faster First Contentful Paint and better Core Web Vitals.
• Brotli decompression is browser-native — Chrome 36+, Firefox 39+, Safari 12+, Edge 14+, iOS Safari 10+, and Samsung Internet 4+ all decode WOFF2 in-process; there is no JavaScript polyfill cost. caniuse.com reports ~96% global support, and the legacy holdouts (pre-2017 IE/old Android stock browsers) are below 0.5% combined traffic.
• Replaces the WOFF + EOT + TTF fallback stack — Pre-2018 @font-face blocks commonly listed four src entries (EOT, WOFF2, WOFF, TTF). With WOFF2 + a single WOFF fallback you cover 99%+ of users, and most modern sites ship WOFF2 only.
• Lossless and feature-complete — Variable font axes (wght, wdth, opsz, slnt), OpenType liga/ss01/cv01 feature tables, kerning, hinting, and color/COLRv1 emoji all survive the conversion. WOFF2 is a container, not a re-encoder — Brotli operates on the bytes of the underlying SFNT table.
• Better for licensing-restricted webfonts — Some commercial foundries (Monotype, Linotype, MyFonts EULA fonts) allow web embedding only via WOFF/WOFF2 because the format historically signals "intended for @font-face delivery." Check your specific license before redistributing.
• Required by modern tooling — Bundlers (Vite, webpack, Rollup, Parcel), static site generators (Astro, Eleventy, Next.js), and font-loading libraries (Fontaine, fontsource) all assume WOFF2 by default. Shipping raw TTF triggers warnings in Lighthouse and PageSpeed Insights.

TTF vs WOFF2 — Format Comparison

WOFF2 vs WOFF — Which Fallback Do You Actually Need?

For most modern sites a single src: url(font.woff2) format("woff2") line is enough. Keep a WOFF fallback only if your analytics show meaningful pre-2018 Safari/Firefox traffic.

Frequently Asked Questions

Will variable font axes survive the TTF to WOFF2 conversion?

Yes. WOFF2 is a container format — it wraps the original SFNT tables (fvar, gvar, STAT, HVAR, MVAR, etc.) byte-for-byte and applies Brotli on top. A TrueType variable font with wght 100–900 and slnt -10–0 axes converts to a WOFF2 with the identical axis definitions and instances, and CSS font-variation-settings: "wght" 650 continues to work as expected. The only caveat is that some older converters predate variable-font support — make sure you're using a current tool. xconvert's converter uses Google's woff2 library logic via opentype.js, which preserves all OpenType tables.

How much smaller will my WOFF2 actually be compared to the source TTF?

Typical Latin-only weights see a ~50% reduction on average, in a 35–65% range (a 200 KB TTF lands around 95 KB — ~52%). CJK and other large-glyph-count fonts see larger absolute savings — Noto Sans CJK SC Regular drops from roughly 9 MB TTF to around 3.5 MB WOFF2. The compression ratio depends on the number of glyphs, the complexity of the curves, and how much of the file is hinting bytecode (which Brotli compresses well). Already-compressed inputs (a font with custom encrypted tables) compress less.

How do I reference the WOFF2 file in CSS?

Use a standard @font-face rule with the format("woff2") token:

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter-regular.woff2") format("woff2");
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

Add font-display: swap to avoid invisible text during font load (FOIT). For critical above-the-fold fonts, also add <link rel="preload" href="/fonts/inter-regular.woff2" as="font" type="font/woff2" crossorigin> to the document head.

Do I still need a WOFF fallback alongside WOFF2?

Probably not. WOFF2 is supported by every major browser: Chrome 36+, Firefox 39+, Edge 14+, and Safari 12+ (macOS 2018); iOS Safari had partial support from Safari 10 (2016) and full support from iOS Safari 12 (2018). caniuse.com puts global support around 96%, and the remaining traffic is mostly pre-2018 in-app browsers and old Android stock WebView. Most new sites ship WOFF2 only. Add a WOFF fallback only if your analytics show measurable traffic from IE11 or Safari 11 and earlier.

Will OpenType features (liga, ss01, kern) work after conversion?

Yes — every OpenType layout table (GSUB, GPOS, GDEF, BASE) carries through unchanged because WOFF2 wraps the SFNT container losslessly. Discretionary ligatures, stylistic sets, tabular figures, slashed zero, small caps, contextual alternates — all of it works in CSS via font-feature-settings or the higher-level font-variant-* properties.

Why does Google Fonts serve me WOFF2 with a slightly different size than my own conversion?

Google Fonts pre-subsets every font into language-specific Unicode ranges (Latin, Latin-extended, Cyrillic, Greek, Vietnamese, etc.) and ships them as separate WOFF2 files via unicode-range in CSS. Their Latin-only WOFF2 is much smaller than your full-Unicode conversion because it contains 200–300 glyphs instead of 1,000+. If you only need Latin, run your TTF through a subsetter (pyftsubset from fonttools is the standard CLI) before converting to match Google's footprint.

Is my font ever uploaded to a server during this conversion?

No. The conversion runs entirely in your browser via a lazy-loaded JavaScript worker (opentype.js handles parsing and Google's woff2.js logic does the Brotli compression). Your .ttf file never leaves the browser session, which matters for unreleased fonts under NDA, commercial fonts with restrictive EULAs, and corporate brand fonts. There's no upload, no server log, no account.

Can I convert a TTC (TrueType Collection) or OTF file the same way?

A TTC file contains multiple fonts in one container — you'd typically split it first with a tool like ttx or fonttools, then convert each face individually. For OTF (PostScript-flavored OpenType with CFF/CFF2 outlines), use the OTF to WOFF2 converter instead; the WOFF2 spec handles both glyf-flavored (TrueType) and CFF-flavored (PostScript) SFNTs, but a few legacy tools choke on CFF inputs.

What's the difference between WOFF2 and just gzipping a TTF on my server?

Two things. First, WOFF2's preprocessing step reorders and transforms the glyph tables before Brotli runs, achieving 5–15% better compression than naively Brotli-ing the raw TTF — gains gzip can't match at all. Second, browsers cache WOFF2 with the correct font/woff2 MIME type and crossorigin semantics, which gzipped-on-the-fly TTF responses don't always get right (CORS, range requests, and the Acceptable-Encoding negotiation can all break in unexpected ways with some CDNs).