WOFF2 vs WOFF vs TTF: Which Font Format Should a Website Serve in 2026?

WOFF2 vs WOFF vs TTF: Which Font Format Should a Website Serve in 2026?

Somewhere in most site audits there is a fonts folder holding the same typeface four times: a TTF from the designer, an OTF from the foundry, a WOFF from an old generator, and a WOFF2 somebody exported once. The CSS loads two of them, the page pays for the weight, and nobody can say which files are actually needed. The answer in 2026 is shorter than the folder suggests: for delivery to browsers, one format does the job, and the rest are sources, fallbacks for museums, or clutter.

This guide explains what each format actually is, what the W3C standardised and when, how the compression differs, and the decision path from a licensed desktop font to the file your @font-face rule should point at. Format history here is not trivia: the dates explain the folder, because each format was the correct answer in its decade.

Which Font Formats to Ship Today

• Serve WOFF2. It is a W3C Recommendation (March 2018), it compresses with Brotli, and every current browser reads it. For a new project, a single WOFF2 source per style is the complete delivery setup.
• Keep WOFF only for genuinely old browsers. WOFF (W3C Recommendation, December 2012) is the same idea with weaker zlib compression. It exists in modern stacks as a fallback for pre-2016 browsers, which most sites no longer need to carry.
• TTF and OTF are source files, not delivery files. They are the installable desktop fonts: full, uncompressed-for-web, and what your licence and your design tools work with. Convert from them, subset the result, and do not point @font-face at them unless you enjoy paying full price in bandwidth for a wrapper's worth of savings forgone.
• EOT and SVG fonts are over. EOT was an Internet Explorer mechanism. SVG fonts were deprecated and dropped. If either is in your CSS, it is archaeology, and removing it changes nothing for any living browser.

Everything after this is the reasoning, the conversion path, and the two licences traps that make designers keep the clutter "just in case".

One Font, Four Containers

The first confusion to clear: TTF and OTF are not rivals to WOFF and WOFF2 in the way the folder implies. They are different layers.

A font file is built on the SFNT structure: a set of named tables holding glyph outlines, metrics, kerning, and layout features. TTF (TrueType) stores outlines as quadratic curves. OTF (OpenType with CFF) stores them as cubic curves from the PostScript tradition. Both can carry the same OpenType layout features (ligatures, alternates, figures), both install on desktops, and the outline flavour rarely matters to a web developer. These are the master files: complete, editable, and licensed for desktop use.

WOFF does not replace that structure; it wraps it. A WOFF file is the same SFNT tables with format-specific compression applied and an XML metadata block added, a design the W3C published as a Recommendation on 13 December 2012 after Mozilla, Opera, and Microsoft submitted the format in 2010. Its media type is font/woff and its files begin with the signature wOFF. The wrapper exists for two stated purposes: to mark a file as intended for the web rather than desktop installation, and to cut the bytes that travel over the network, since WOFF compresses the tables with zlib.

WOFF2 is the second iteration of the wrapper, standardised as a W3C Recommendation in March 2018. It keeps the same job and changes the machinery: the font tables are compressed as a single stream with Brotli, the compression algorithm Google built for web assets, and the glyph tables are restructured before compression to squeeze out redundancy zlib cannot reach. Its media type is font/woff2 and its signature is wOF2. Reported comparisons from the standardisation work put WOFF2 files at roughly 30 percent smaller than their WOFF equivalents for the same font, which is why the industry standardised a second format only six years after the first.

So the folder makes sense once you see the layers: TTF/OTF are the font, WOFF/WOFF2 are envelopes for posting it. Serving the master file to browsers is like emailing the print-ready file instead of the PDF: it works, and it wastes everyone's bandwidth. Print runs the other way: a press-ready PDF/X file must carry every font embedded inside it, which is why desktop font licenses address PDF embedding, a step the PDF/X-1a vs PDF/X-4 guide walks through.

Does the Format Change How the Font Looks?

No, and this settles an argument that keeps folders fat. WOFF and WOFF2 are lossless wrappers around the same tables: decompressed, the browser renders the identical outlines, metrics, and layout features as the source TTF or OTF. A character does not become smoother, sharper, or different in WOFF2. What changes is delivery: how many bytes travel, and how fast the real font can replace the fallback. Rendering differences people blame on format almost always trace back to different font versions, different weights being served, or hinting differences between two different source files, not to the wrapper. The web font loading guide covers the failures that actually change what visitors see.

One honest exception: converting between outline flavours (TrueType to CFF or back) is a real conversion that can alter outlines subtly, and some conversion tools do it without saying so. Converting TTF or OTF to WOFF2 with a maintained tool such as fonttools keeps the flavour and changes only the envelope. Stay on that path.

The Decision Path: Desktop Font to Served Font

Work through these five steps in order. Each one removes a reason the clutter exists.

1. Confirm the licence covers web use, before any tool runs. A desktop licence is not a web licence. Foundries sell web use by domain, pageviews, or as a separate webfont package, and the commercial font licensing guide works through those models. Open licences (the SIL Open Font License above all) allow conversion and subsetting, with conditions. Some commercial licences forbid you converting the file yourself and require the foundry's own generated webfonts. This step decides whether steps 2 to 4 are yours to do at all.

2. Convert the licensed source to WOFF2. Use the foundry's generator when the licence requires it, or fonttools (the open font engineering library) when it does not. The conversion is lossless for outlines and features. Discard intermediate WOFF unless a named legacy browser is a real requirement with real traffic behind it.

3. Subset to the characters the site actually uses. A full font carries every script and symbol its designer drew; a Latin-language marketing site uses a few hundred glyphs. Subsetting strips the rest. fonttools' pyftsubset does it in one command, and the standard practice (documented in SitePoint's web font optimisation guide, read for this article) is to pass the Unicode ranges the site needs and keep the layout features, because dropping kerning and ligature tables saves bytes by degrading the type. Two cautions belong here: subsetting is a modification, so check the licence allows it, and a subset that drops a glyph a page later needs produces the mixed-font words described in the troubleshooting guide.

4. Decide static weights or one variable file. If the design uses two or three weights, subsetted static WOFF2 files are usually the lighter total. If it uses a real range, one variable WOFF2 can replace the set, and the variable fonts guide works through where that trade tips. Either way, count requests: every file in the CSS is a download a visitor's connection has to make.

5. Write the @font-face rule for what you actually ship. One src, the WOFF2 file, with the correct format hint, a font-display value chosen on purpose, and nothing else:

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

The format() hint tells the browser what the file is before it downloads, so it can skip anything it cannot use. The font-display value decides what text looks like while the file travels; leaving it unset is itself a choice, and usually the wrong one.

Serving Part of the Font: Subsets and unicode-range

Step 3 subsets once, for the whole site. Sites with mixed content can go further and split the font by script, serving each piece as its own WOFF2 behind a unicode-range declaration in the @font-face rule. The descriptor gives the Unicode code points that file covers; the browser reads the ranges on offer, checks which ones the page's actual text touches, and downloads only those files. A page written entirely in English never downloads the Cyrillic or Greek pieces at all, and a page with one Greek product name downloads the Latin piece plus the one small piece that covers it.

This is the arrangement Google Fonts uses when it serves a family in slices named latin, latin-ext, cyrillic, greek, vietnamese and so on, and it is the natural end point of the subsetting step for a self-hosted font: pyftsubset produces each piece from the same licensed source, and each piece gets its own @font-face rule with the same family name and its own unicode-range. The discipline that makes it work is accuracy in the ranges. A range declared too narrow recreates the mixed-font failure from the troubleshooting guide, where characters the file does not cover arrive in a fallback face mid-word; a range declared too wide just downloads more than the page needed, which is wasteful but harmless. When in doubt, declare wide and let subsetting, not the range, do the cutting.

The Metadata That Travels With the File

One part of the wrapper design rarely gets mentioned: both WOFF and WOFF2 carry an optional extended metadata block, XML text stored alongside the compressed tables. The W3C designed it so a font's vendor, designer, licence and licensee information can travel inside the file itself rather than in a separate document that gets separated from the font the first time the folder is copied. Browsers do not display it and CSS cannot read it, but it is there when an audit asks where a file came from and under what terms it may be served.

That is worth one habit: when you generate webfonts, let the tool write the metadata, and when you receive a webfont package from a foundry, check whether the metadata names the licence you bought. A file that arrives with another organisation's licensee name in its metadata is a file that was generated under somebody else's licence, and serving it is a problem the formats cannot fix. The wrapper was designed, in part, to make exactly that check possible.

A Worked Audit, End to End

Take the folder from the opening paragraph, made concrete: one family, two weights (regular and bold), present as TTF, OTF, WOFF and WOFF2, eight delivery files in the web root, with CSS from three different years referencing four of them. Run the decision path in order. The licence check finds an Open Font License release, so conversion and subsetting are permitted and the foundry's own generator is not required. The TTF and OTF turn out to be two cuts of the same family, so one is chosen as the master and archived with the licence text; the other leaves the project. Conversion produces fresh WOFF2 from that master, subsetted to the Latin and Latin-extended characters the site's content actually uses, including the accented names in its author bylines. The variable-font question answers itself: two weights, statically subsetted, are lighter than one variable file spanning a range the design never touches. The rewritten CSS carries two @font-face rules, one per weight, each with one WOFF2 source, a format hint, and font-display: swap. The EOT and SVG lines from the oldest stylesheet are deleted. The web root's font folder goes from eight served files to two, the masters live in the project archive instead of the deployment, and every byte a visitor downloads is a byte the page uses. Nothing about how the type looks has changed, because the wrapper never changed how the type looks; only the folder, the requests, and the bill changed.

What to Do With the Existing Clutter

For a site already carrying four formats, the cleanup order is safe and mechanical:

1. Check which files the live CSS actually references. Unreferenced files in the folder are not fallbacks, they are dead weight; remove them from the repo after one deploy cycle proves nothing requests them.
2. If the CSS lists TTF or OTF sources, generate WOFF2 from the same licensed sources, swap the references, and keep the masters in the project archive, not the web root.
3. If the CSS lists WOFF ahead of WOFF2, reorder or drop the WOFF line: browsers take the first source they understand, and the order in the rule is the priority order.
4. Remove EOT and SVG sources outright. No living browser needs them, and every extra source line is a future editor's confusion.
5. Re-check the licence paperwork once the folder is clean, and file the web licence next to the masters. The Google Fonts guide covers the same discipline for library fonts: few files, known licence, deliberate loading.

Frequently Asked Questions

How do I check which font file a page is actually using?

Open the browser's developer tools, switch to the Network panel, filter by font, and reload the page. Each font request shows its file name, its format, its transferred size, and whether it came from cache. If you see a TTF or OTF file where you expected WOFF2, the @font-face rule probably lists the formats in the wrong order or the WOFF2 path is wrong, so the browser fell through to the next source. If you see no font request at all, the browser either matched a locally installed font through a local() source or never needed the face, because no element used that weight or style. Both cases change what your visitors see compared with your own machine, which is why this check belongs in every font audit.

Does the format affect how text appears while the font loads?

No. Loading behaviour is controlled by the font-display descriptor in the @font-face rule, not by the container format. A WOFF2 file simply arrives sooner because it is smaller. The descriptor accepts auto, block, swap, fallback and optional; swap shows fallback text immediately and replaces it when the font arrives, while optional lets the browser keep the fallback if the font is late. Our web fonts troubleshooting guide covers how to choose between them.

Can browsers just use the TTF file directly?

Yes, technically: browsers will download and render a TTF or OTF from an @font-face rule, and small internal tools do it all the time. For a public site it is a poor trade. You pay the full uncompressed size on every visitor's connection, give up the metadata and the web-intent marking the wrapper exists to provide, and gain nothing in rendering, because the wrapper is lossless. Convert once, serve WOFF2 forever.

Is WOFF2 supported by every browser?

Every current browser, yes: Chrome, Firefox, Safari, and Edge have all read WOFF2 for years, which is why a WOFF2-only setup is the practical default for new work. The browsers that cannot read it are pre-2016 versions. Whether that audience matters is a question about your own analytics, not about the format; if a named legacy browser genuinely drives your traffic, add WOFF as a second source and let the format hints sort it out.

How much smaller is WOFF2, really?

The figure reported from the W3C standardisation work is roughly 30 percent smaller than WOFF for the same font, thanks to Brotli and the table restructuring, and WOFF itself is substantially smaller than the raw TTF or OTF. Treat the percentages as typical, not promised: the exact saving depends on the font's tables. Subsetting, which removes glyphs entirely, usually saves more than the format change does, which is why the decision path subsets after converting.

Does converting a font change its licence?

No. Conversion changes the container, never the rights. A converted file carries the original licence with it, including its limits: if the licence forbids conversion, or requires the foundry's own webfont package, converting it yourself is a breach no matter how standard the tool. Open Font License fonts are the comfortable case: conversion and subsetting are allowed, with the licence kept with the files. When in doubt, the licence text, not the tool's capability, is the authority.

Should I serve a variable font or static weights?

Count what the design uses. Two or three weights: subsetted static WOFF2 files are typically lighter and simpler. A genuine range of weights, or width and optical axes in real use: one variable WOFF2 replaces a shelf of statics and lets CSS pick exact values. The variable fonts guide runs the comparison in full, including the failure mode where a variable file with a wide axis range outweighs the three statics it replaced.

What if the design uses system fonts, with no font files at all?

Then none of this applies, and that is a legitimate endpoint rather than a gap. A stack built on the fonts already installed on the visitor's system (the ui-sans-serif and system-ui families and their relatives) downloads nothing, needs no licence check beyond the operating system's own, and cannot fail to load. Sites choose it when the brand allows it and speed outranks a distinctive face. The formats in this guide matter the moment a specific typeface is part of the design, because then files exist, licences apply, and somebody has to decide which container the files travel in.

What happened to EOT and SVG fonts?

EOT was Microsoft's Internet Explorer embedding mechanism, never a cross-browser standard, and it died with the browser versions that needed it. SVG fonts put glyphs in an SVG vocabulary; the idea was deprecated, other engines never adopted it fully, and it was removed. Both survive only in old tutorials and old CSS. Delete the lines.

Sources Read for This Guide

• W3C, WOFF File Format 2.0 (Recommendation, 1 March 2018), w3.org/TR/WOFF2: the single-stream Brotli compression of the font tables, the file structure, and the wOF2 signature.
• W3C, WOFF File Format 1.0 (Recommendation, 13 December 2012), and the format's standardisation history as summarised from the W3C record: the 2010 submission by Mozilla, Opera, and Microsoft, the zlib wrapper design, and the font/woff media type.
• SitePoint, How to Optimize Web Fonts: WOFF2, Subsetting, and Loading Without Layout Shift (2026): the fonttools subsetting workflow, the layout-features caution, and the static-versus-variable weighing in practice.

Format percentages are the typical reported figures from the standardisation literature, not measurements of your font; subset a copy and weigh it if the exact number matters to a budget.