Convert OTF to WOFF for Web Font Delivery

What an Embedding-Permission Bit Has to Do With This Conversion

Every OTF file carries a 16-bit fsType field inside its OS/2 metadata table, a value font foundries set to declare how the font is allowed to be embedded elsewhere: 0 for Installable (no restriction), 2 for Restricted (no embedding permitted), 4 for Print and Preview only, or 8 for Editable embedding. Desktop applications like Adobe Acrobat and Microsoft Word are built to check and honor this flag before allowing a font to be embedded inside a saved document. Converting an OTF file to WOFF for web use sits in an interesting gap here: WOFF, the Web Open Font Format standardized by the W3C in December 2012, was specifically designed for exactly this kind of embedding, loading a font over the web into a browser rather than a desktop document, yet web browsers themselves are documented to ignore the fsType flag completely, regardless of what value the font's metadata carries.

That gap means the technical conversion from OTF to WOFF works identically no matter what the fsType flag says, but the font's actual license terms, a separate legal document from the file's internal metadata, are the real authority governing whether this specific use is permitted. A font marked Restricted might still convert to WOFF without any technical error, since nothing in the conversion process itself enforces that flag, which is precisely why relying on fsType as a stand-in for checking the license is a documented, real source of licensing problems for people using purchased fonts on websites.

How a CFF-Flavored Font Gets Folded Into WOFF's Own Wrapper

Structurally, converting OTF to WOFF means taking the font's existing sfnt-format tables, whether CFF-flavored (cubic Bézier, "OTTO" signature) or TrueType-flavored (quadratic Bézier, glyf table), and compressing them using zlib-based DEFLATE compression, the same general-purpose compression algorithm used in ZIP files, applied per-table inside a WOFF-specific container header. Unlike WOFF2's successor design, WOFF 1.0 doesn't apply any special glyph-specific reorganization before compressing, meaning both CFF and TrueType-flavored source data get compressed by the same general-purpose method, with no outline-flavor-specific advantage or disadvantage built into WOFF's compression scheme itself.

This is a real, structural difference from WOFF2, whose specification defines a special transform applied specifically to TrueType glyf, loca, and hmtx table data to make it compress harder under Brotli, a transform that simply isn't defined for CFF-flavored data at all. WOFF's simpler, uniform compression approach means a CFF-flavored OTF file and a TrueType-flavored one see roughly comparable compression benefits when converted to WOFF, a genuine point of contrast worth knowing before assuming WOFF and WOFF2 behave identically across outline flavors, since they don't.

The WOFF container also carries an optional metadata block, capable of storing structured XML text about the font's license, vendor, and credits directly inside the file itself, separate from the fsType flag discussed above. A font foundry can choose to include this metadata when generating a WOFF file, and while it's genuinely optional and not every conversion tool preserves it by default, its presence is one of the few features WOFF added on top of a plain OTF file rather than one it lost during the wrapping process.

The WOFF specification defines a specific schema for that optional metadata block, with named XML elements including vendor for the foundry's name and URL, credits for listing individual contributors, description for free-text notes about the font, and separate license, copyright, and trademark elements each capable of holding both plain text and a linked URL. None of these elements are required, and a conversion tool building a WOFF file from a plain OTF source with no matching metadata already present typically just leaves this block out entirely, since there's nothing in a standard OTF file that maps directly onto this WOFF-specific structure.

What Changes Once a Desktop OTF Becomes a Web WOFF

• Gain — a smaller file specifically for browser delivery: zlib-based compression reduces transfer size compared to sending the raw, uncompressed OTF table data directly.
• Lose — desktop installability: WOFF is a web-delivery wrapper only; the file can't be double-clicked and installed as a system font the way the original OTF could.
• Risk — the fsType flag stays present but gets ignored by browsers: the embedding permission value carries through unchanged in the file's metadata, but no browser actually checks it before loading the font.
• Gain — a W3C-standardized, near-universal web format: WOFF has broad support across both current and many older browser versions still in limited use.
• Lose — no outline-flavor-specific compression advantage: unlike WOFF2, WOFF's compression treats CFF and TrueType-flavored data the same way, without a special reorganization step for either.
• Risk — subsetting or metadata errors carrying through unnoticed: if the original OTF was already missing certain glyphs, the WOFF version inherits that same incomplete character set.

Which Browsers Actually Honor What's Inside That Wrapper

WOFF carries broad support across every currently maintained browser, Chrome, Firefox, Safari, and Edge, and remains readable by a meaningful number of older browser versions that predate WOFF2's later rollout, which is why it still functions as a sensible fallback format listed after WOFF2 in a CSS @font-face declaration's src list. What no browser does, regardless of version, is check the font's fsType embedding permission flag before loading it, a documented gap discussed directly on W3C's own public web-fonts mailing list archives, meaning the technical loading behavior of a WOFF file is entirely independent of whatever embedding restriction its metadata claims to carry.

Desktop applications behave in the opposite way: Word and Acrobat specifically check fsType before permitting embedding inside a saved document, which is precisely why the same font file can be freely usable on a website, where the browser never checks that flag, while still being blocked from embedding in a PDF or Word file on someone's desktop, where the application does check it. Understanding this split is the difference between a technically working conversion and one that's actually compliant with the font's real license terms.

Why a Licensed Font Can Convert Fine and Still Get You in Trouble

A specific, real complaint that surfaces on font marketplace support pages and design forums involves someone converting a purchased desktop-license OTF font to WOFF, publishing it on a live website, and later receiving a licensing notice, even though the technical conversion itself produced a perfectly functional file with no errors. The cause is almost never technical, it's that many commercial font licenses separately distinguish "desktop use" from "web use" as different purchasable tiers, and a desktop license alone often does not automatically cover embedding that same font on a public website, regardless of what the file's own fsType metadata says or whether the conversion technically succeeds.

The practical, checkable fix is reading the specific font's license terms directly on the marketplace or foundry's own site before converting and publishing anything, since the license document, not the file's internal fsType flag, and certainly not whether the browser happens to load the file successfully, is the actual binding authority on what's permitted. A font converting without any technical error is not the same thing as a font being licensed for that specific use.

Some marketplaces address this directly by selling a distinct "webfont license" alongside the standard desktop license, sometimes priced by expected monthly pageviews, specifically so a purchaser doesn't have to guess whether their existing purchase already covers this exact use case. Checking for that option before assuming a standard desktop license silently extends to web use is worth the extra few minutes it takes.

Desktop Container Against Web Container, Feature by Feature

Questions About Moving a Purchased OTF File Onto a Website

Does my font's fsType embedding flag stop it from working as a WOFF web font?
No. Browsers ignore the fsType flag entirely, so a converted WOFF file will load regardless of what that flag says. The font's actual license terms, not this metadata field, govern whether the use is permitted.

Why did I get a licensing notice after converting and publishing a font I paid for?
Many commercial font licenses sell "desktop use" and "web use" as separate tiers. A desktop license doesn't automatically cover website embedding, regardless of whether the technical conversion succeeded.

Does converting to WOFF compress a CFF-flavored font differently than a TrueType one?
No, not meaningfully. WOFF 1.0 uses the same general-purpose zlib compression for both outline flavors, unlike WOFF2, which applies a special transform only to TrueType-flavored data.

Can I still install the WOFF version on my own computer?
No, WOFF is a web-delivery format only. You'd need to keep the original OTF file, or convert back to it, to install the font as a desktop system font.

What kind of license information can actually be embedded inside a WOFF file?
The WOFF specification defines an optional metadata block with named elements for vendor, credits, description, license, copyright, and trademark information, each able to hold both text and a linked URL. Whether any of it is filled in depends entirely on the foundry or conversion tool that built the file; a plain OTF-to-WOFF conversion with no source metadata typically leaves this block empty.