What Is a WOFF File? Web Open Font Format Explained

The Format Three People Built Specifically to Fix Web Type

WOFF, the Web Open Font Format, was first proposed in July 2009 by Jonathan Kew, a software engineer at Mozilla, in collaboration with two practicing type designers: Erik van Blokland of the foundry LettError and Tal Leming of Type Supply. Before this, embedding a custom font on a website meant either linking to a raw, uncompressed TTF or OTF file, which most type foundries refused to allow since anyone could then simply download and reuse the font without a license, or relying on Microsoft's older EOT format with its built-in digital rights management, which no other browser maker adopted. WOFF's specific proposal was a wrapper format combining real compression with a metadata block for licensing information, something both foundries and browser makers could actually agree to support.

That collaboration produced a W3C Member Submission on April 8, 2010, formally filed by Mozilla, Opera Software, and Microsoft together, and the format reached full W3C Recommendation status in 2012, at which point every major browser maker had implemented it. A reader encountering a request for "the WOFF version" of a font today is being asked for exactly this: the same underlying TrueType or OpenType outline data, repackaged specifically for efficient, licensed delivery over the web rather than local installation.

The push toward WOFF actually started a few years earlier as a reaction against Microsoft's EOT format. CSS co-creator Håkon Wium Lie began publicly campaigning in 2008 for browsers to support real web font embedding using standard TrueType and OpenType data rather than EOT's proprietary, DRM-locked approach, and most browser vendors responded by asking the W3C to define a new, shared format instead of adopting EOT themselves, largely because they preferred reusing gzip-style DEFLATE compression, already built into every browser for HTTP, rather than implementing Microsoft's separate MicroType Express algorithm from scratch.

What's Actually Inside a .woff File, Byte by Byte

A WOFF file consists of a 44-byte header, followed by a table directory, then the actual font tables, an optional block of XML metadata, and an optional block of private data. The header records both the compressed and original uncompressed size of every table so a browser can allocate memory correctly before unpacking anything. Each font table, the glyf outline data, the cmap character map, and the rest, gets compressed individually using zlib, the same DEFLATE-based algorithm gzip uses, rather than compressing the whole file as one combined stream.

Every block inside the file, whether a compressed table, the metadata, or the private data, gets padded with up to three null bytes to keep it aligned on a 4-byte boundary. None of this changes a single glyph outline or hinting instruction; WOFF is a fully lossless wrapper, meaning decompressing a .woff file reconstructs the exact original sfnt-based TrueType or OpenType data it was built from, which is why converting a font to WOFF and back produces a byte-identical result.

The WOFF specification also gives an encoder an escape hatch on a table-by-table basis: if zlib compression would actually make a specific table larger, or no smaller, than its original size, the spec permits storing that table's raw, uncompressed bytes instead, since forcing compression on data that doesn't shrink would only waste processing time for no benefit. The optional XML metadata block, when present, follows a schema the WOFF specification defines directly, with dedicated elements for a unique identifier, vendor name and URL, credited designers, a plain-text description, copyright and trademark notices, and full license text, all of which a browser ignores for rendering purposes but which a font-management tool can read back out later.

Where This Format Still Earns Its Place in a Font Stack

• Gain — over 40% smaller than a raw TTF: zlib's per-table compression trims file size substantially with zero loss of glyph or hinting detail.
• Gain — earlier, broader legacy browser support than WOFF2: WOFF reached major browsers years before WOFF2 existed, including Internet Explorer 9 in 2011.
• Lose — desktop installability: a .woff file has to be converted to TTF or OTF before an operating system will install it as a usable font.
• Lose — compression efficiency compared to WOFF2: WOFF2's Brotli-based, whole-font approach typically produces files 30 to 40 percent smaller than the same font in WOFF.
• Gain — a built-in metadata block for licensing: the optional XML metadata block was specifically designed to carry foundry and license information alongside the font data itself.
• Gain — a legitimate current role as a fallback format: listed second after WOFF2 in a CSS @font-face rule, WOFF still covers the small remaining band of browser versions that never added WOFF2 support.

The Version Numbers Behind "Nearly Universal" Support

WOFF's rollout across browsers happened well before WOFF2 was even proposed: Firefox added support in Firefox 3.6 in 2010, and by the time the format reached full W3C Recommendation status in 2012, Chrome, Safari, and Internet Explorer 9 had all implemented it too. This is a meaningfully earlier and broader rollout than WOFF2 saw, since WOFF2 didn't reach its own W3C Recommendation until 2018, and Internet Explorer never added WOFF2 support in any version at all.

That history is exactly why WOFF hasn't disappeared even though WOFF2 offers stronger compression: any browser version old enough to lack WOFF2 support but still capable of reasonably modern web browsing typically does support WOFF, since WOFF's own rollout reached that generation of browsers years earlier. The standard practice of listing WOFF2 first and WOFF second in an @font-face declaration exists specifically to take advantage of that gap.

The Recurring Complaint Threads About This Format

A frequently reported issue involves a WOFF file that previews correctly on a local machine but fails to load once the site goes live, with the browser's developer tools showing a blocked or failed font request rather than a visible rendering bug. Forum threads on this consistently trace it back to the web server sending an incorrect MIME type for the .woff file, commonly application/octet-stream or text/html instead of the correct font/woff, which modern browsers with strict MIME-type checking will refuse to load as a font regardless of whether the underlying file is perfectly valid; adding an explicit MIME type mapping in the server's configuration is the reported fix.

A second, distinct complaint involves the CSS format() hint inside an @font-face rule being wrong or omitted; the W3C specification is explicit that browsers use this hint, not the server's MIME type, to decide whether to even attempt downloading a particular font source, so a missing or mismatched format('woff') string can cause a browser to silently skip a completely valid file.

A third, less common report involves a WOFF file rejected outright by Chromium or Firefox's built-in OpenType Sanitizer, visible in the browser console as an "OTS parsing error" naming a specific malformed table, such as an invalid sfntVersion tag or a glyph the sanitizer couldn't parse. Since OTS exists specifically to reject fonts as a security precaution against malformed data, this points to actual file corruption, most often introduced by a build tool or CDN mishandling the binary file as text somewhere between conversion and the live server, rather than a flaw in the WOFF format itself.

This Format Set Beside the Newer Standard That Replaced It

Frequently Asked Questions About This Web Font Wrapper

Who actually created the WOFF format?
Jonathan Kew of Mozilla proposed it in 2009 working with type designers Erik van Blokland and Tal Leming; it became a W3C Recommendation in 2012 after every major browser maker implemented it.

Is WOFF still worth using now that WOFF2 exists?
Yes, as a fallback. WOFF reached broad browser support years before WOFF2 did, so listing it second in your CSS covers older browser versions that never added WOFF2 support.

Can I install a WOFF file directly like a regular font?
No. It has to be converted to TTF or OTF first; WOFF is a web-delivery wrapper only, never installable directly on Windows or macOS.

Does WOFF compression lose any quality compared to the original font?
No. Zlib compression inside WOFF is fully lossless; decompressing a WOFF file reconstructs the exact original outline and hinting data byte for byte.

What actually goes inside a WOFF file's optional metadata block?
The W3C specification defines a specific XML schema for it, with dedicated elements for a unique font identifier, the vendor's name and URL, credited designers, a text description, copyright and trademark notices, and full license text. Browsers ignore this block entirely when rendering; it exists for font-management tools and licensing audits to read back later.

Why was WOFF created instead of browsers just adopting Microsoft's EOT format?
Most browser vendors preferred building on gzip-style DEFLATE compression, already implemented in every browser for HTTP, rather than adding support for EOT's separate MicroType Express algorithm, and CSS co-creator Håkon Wium Lie had been publicly campaigning since 2008 for standard TrueType and OpenType embedding instead of a DRM-locked proprietary format.