TTF vs OTF vs WOFF2: Font Format Comparison
A Quick History of These Three Formats
TrueType (TTF) arrived in 1989 as a joint project between Apple and Microsoft, designed to give operating systems direct control over font rendering without relying on Adobe's PostScript licensing. It stores glyph outlines as quadratic Bézier curves and packages everything — metrics, hinting instructions, kerning tables — into a single binary file. For most of the 1990s it was the dominant desktop font format on both Windows and macOS. OpenType (OTF) followed in 1996, developed by Microsoft with Adobe joining shortly after. Rather than replacing TrueType's container entirely, OpenType extended it. An OTF file can internally use either TrueType quadratic curves or Adobe's cubic PostScript curves (CFF outlines), which is why you sometimes see the term 'CFF-based OTF.' The format also introduced a rich set of layout tables — GSUB and GPOS — that enable features like ligatures, small caps, swashes, and contextual alternates. A well-built OTF for a complex script like Arabic or Devanagari can contain thousands of glyph substitution rules. WOFF2 (Web Open Font Format 2) is a different kind of beast. Released as a W3C Recommendation in 2018, it is not a new outline format but a compression wrapper. It takes an existing TTF or OTF font, applies Brotli compression plus a specialized font-aware pre-processing step called 'transformed tables,' and produces a file that is typically 30–50% smaller than the original. WOFF2 was built exclusively for web delivery; browsers decompress it on the fly before rendering, so it never touches your operating system's font manager. Understanding that distinction — outline format versus delivery format — is the single most important thing to grasp before choosing between these three.
File Size and Compression: The Numbers That Actually Matter
Raw file size affects page load times, app bundle sizes, and CDN bandwidth costs, so concrete numbers are worth examining. Take a moderately complex Latin typeface like Source Sans Pro Regular. Its TTF weighs roughly 260 KB. The OTF version of the same font, using CFF outlines, comes in around 155 KB — CFF's cubic curves tend to describe the same shapes with fewer points than TrueType's quadratic curves, which is why CFF-based OTFs are often 20–40% smaller than their TTF counterparts for Latin scripts. Convert that same font to WOFF2 and you land at approximately 75 KB, a 71% reduction from TTF and 52% from OTF. For a CJK (Chinese, Japanese, Korean) font the story shifts. A full-coverage CJK TTF like Noto Sans CJK SC can exceed 20 MB. WOFF2 compression still helps — you might get it down to 13–15 MB — but the real solution there is subsetting, which is a separate concern from format choice. WOFF2 alone will not rescue a font that contains 65,000 glyphs. WOFF (version 1, without the '2') used zlib compression and is now largely obsolete. Browser support for WOFF2 reached 97%+ of global users as of 2024 according to caniuse.com data, covering every modern browser including Chrome 36+, Firefox 39+, Safari 12+, and Edge 14+. The only scenario where WOFF2 support becomes uncertain is very old embedded browsers in smart TVs or legacy enterprise kiosks running Internet Explorer 11, which supports WOFF but not WOFF2. For virtually all new web projects, WOFF2 is the right default.
OpenType Features: Where OTF Genuinely Outperforms TTF
The most substantive technical difference between a well-crafted OTF and a TTF is access to OpenType layout features. These are defined in the GSUB (Glyph Substitution) and GPOS (Glyph Positioning) tables, and both TTF and OTF files can technically contain them — but in practice, professional type foundries build their advanced feature sets almost exclusively into OTF releases. Consider what those features enable. Ligatures replace glyph sequences like 'fi' and 'fl' with a single merged glyph that avoids the dot of the 'i' colliding with the hook of the 'f.' Discretionary ligatures go further, combining 'ct,' 'st,' or 'Th' pairs for a calligraphic feel. Small caps substitute full-height capitals with optically sized smaller versions — not just scaled-down caps, but redrawn glyphs. Oldstyle figures replace the default lining numerals with figures that have descenders, like the digit '3' dropping below the baseline. A single OTF file for a typeface like Minion Pro contains over 1,700 glyphs and dozens of feature tags including 'onum,' 'smcp,' 'calt,' 'swsh,' and 'hist.' In CSS, you activate these via font-feature-settings: 'onum' 1; or the higher-level font-variant-numeric: oldstyle-nums;. In Adobe InDesign, go to Type > OpenType and the submenu lists available features for the active font. In Microsoft Word 365, they appear under Format > Font > Advanced tab, though coverage is limited compared to InDesign. A TTF file that lacks these tables will simply not offer these capabilities, regardless of which application you use. If your project depends on proper small caps, contextual alternates, or script-specific shaping for Arabic or Indic text, OTF is not optional — it is the only format that reliably delivers.
Hinting and Rendering: Desktop vs. Screen Contexts
Font hinting refers to instructions embedded in a font file that adjust glyph outlines at small pixel sizes so that strokes align cleanly to the pixel grid. Without hinting, a 12px 'n' might have one stem rendered at 1 pixel wide and another at 2 pixels, creating uneven weight. Good hinting makes small text look crisp on lower-resolution displays. TTF fonts traditionally carry manual TrueType hinting, written in a stack-based bytecode language that gives type designers fine-grained control over every glyph at every point size. This is extremely labor-intensive — a fully hand-hinted Latin font like Arial or Times New Roman represents hundreds of hours of work. The payoff was significant on Windows XP and earlier systems, which used a hinting-dependent renderer called GDI. CFF-based OTF fonts use PostScript hinting, which is simpler and less granular. On macOS, which uses a sub-pixel anti-aliasing renderer that largely ignores hinting instructions, this difference is invisible. On Windows with ClearType enabled (the default since Vista), the gap has narrowed considerably. On high-DPI displays — anything above 192 PPI, which covers most modern phones and Retina MacBooks — hinting matters almost not at all, because individual pixels are too small to cause the alignment problems hinting was designed to fix. For WOFF2, the hinting data is preserved from whatever source font was compressed. If you convert a well-hinted TTF to WOFF2, the hints travel with it. If you convert a CFF OTF, the PostScript hints come along. So WOFF2 does not change the hinting story — it just wraps it more efficiently. The practical takeaway: if your primary audience uses Windows on standard 96 DPI monitors and your text will appear at sizes below 16px, a well-hinted TTF has a real, measurable advantage. For web use on modern hardware, the difference is negligible.
When to Use Each Format: A Practical Decision Guide
Desktop application installation — operating systems, design software, office suites — requires either TTF or OTF. Windows and macOS both support both formats natively. Linux distributions using FreeType also handle both without issues. The choice between TTF and OTF for desktop installation comes down to whether you need advanced OpenType features (favor OTF) or maximum compatibility with older Windows rendering (favor TTF). For a corporate font deployed via Group Policy across a Windows 10 fleet where some machines lack ClearType tuning, a hinted TTF is the safer choice. For a design agency installing a typeface in InDesign to be used at display sizes with ligatures and swashes, OTF is clearly better. Web delivery is where WOFF2 dominates. Your CSS @font-face declaration should list WOFF2 first: src: url('font.woff2') format('woff2'), url('font.woff') format('woff');. Serving a raw TTF or OTF over HTTP is wasteful — you are sending 2–3x more bytes than necessary. Some legacy CMS themes still reference TTF in their stylesheets; replacing those references with WOFF2 equivalents is a quick performance win. Mobile apps present a mixed picture. iOS supports OTF and TTF natively; Android has supported both since API level 16 (Jelly Bean). Neither platform uses WOFF2 for bundled app fonts — that format exists only in the browser context. Flutter apps bundle TTF or OTF in the assets directory and reference them in pubspec.yaml. React Native follows the same pattern. Game engines vary: Unity's TextMeshPro accepts OTF and TTF for font asset generation. Unreal Engine's font importer works with TTF. Neither currently imports WOFF2 directly, so if you only have a WOFF2 file you need to convert it back to TTF or OTF first.
Converting Between Formats with CocoConvert
CocoConvert handles the most common font conversion paths: TTF to WOFF2, OTF to WOFF2, WOFF2 to TTF, and OTF to TTF (and the reverses). The conversion process uses fonttools, the same Python library that powers Google Fonts' pipeline, so the output is standards-compliant and preserves OpenType tables including GSUB, GPOS, name records, and hinting data where applicable. To convert a TTF to WOFF2, upload your .ttf file on the font conversion page, select WOFF2 as the output format, and click Convert. Processing a typical 200–300 KB Latin font takes under five seconds. The resulting WOFF2 file retains all the original font's metrics and layout features — nothing is stripped by default. A few honest limitations worth knowing: CocoConvert does not perform subsetting. If you upload a 20 MB CJK font and convert it to WOFF2, you get a compressed 13 MB WOFF2, not a lean 50 KB subset. For subsetting, tools like pyftsubset (part of fonttools) or the Google Fonts subsetting service are better suited. CocoConvert also does not modify or strip font licensing metadata. If a font's name table contains an embedding restriction flag (fsType = 2, meaning 'Print and Preview' only), that flag persists in the converted file. Converting a restricted font to a web format does not grant you the right to serve it on a website — check your license. Converting WOFF2 back to TTF is useful when you have a web font and need to install it on a desktop or use it in a game engine. The decompression is lossless; the TTF output is byte-for-byte equivalent in terms of outline data to the original source that was compressed into WOFF2. The one caveat: if the WOFF2 was created from a 'transformed' glyf table (a WOFF2 optimization that reorganizes TrueType curve data), CocoConvert's conversion reverses that transformation cleanly.
Summary: Choosing the Right Format Without Overthinking It
The three formats serve three distinct purposes, and the confusion usually comes from treating them as interchangeable alternatives rather than tools for different jobs. TTF is the universal baseline. Every platform that handles fonts at all handles TTF. It is the right choice when you need broad compatibility, when you are targeting older Windows environments where manual hinting matters, or when a downstream tool (a game engine, an older design application) does not accept OTF. Its main weakness is file size compared to CFF-based OTF, and it typically lacks the advanced typographic features that professional OTF releases include. OTF is the professional desktop format. When a type foundry sells you a typeface for serious editorial or branding work, the OTF is the version you want. It carries the full OpenType feature set, CFF outlines are generally more compact than TrueType for Latin scripts, and every modern operating system and design application supports it. Its only real limitation is that it is not a web delivery format — serving raw OTF over HTTP wastes bandwidth. WOFF2 is the web delivery format. Full stop. It is not a new type of font; it is an existing font compressed for the browser. Always use WOFF2 in @font-face declarations for modern browsers. Keep the original TTF or OTF on your server or local machine as the source of truth; the WOFF2 is a derived artifact for delivery. If you are starting a project from scratch and need to serve a font on the web, the workflow is: obtain a quality OTF from the foundry, convert it to WOFF2 for web use, and keep the OTF for any desktop or print work. If you only have a WOFF2 and need a desktop-installable file, convert it back to TTF. CocoConvert handles both directions without requiring any font software installation on your end.