History of Web Fonts: From @font-face to WOFF2

Early Web Typography

In the early days of the web (1991–1997), typography was severely constrained by the browser's fundamental architecture. Web pages could only display fonts already installed on the user's operating system. Since font installation varied widely between users, designers could only safely reference fonts they could reasonably expect to find on most computers. This gave rise to the concept of "web-safe fonts" — a short list of typefaces common enough to assume near-universal availability.

The web-safe font list that designers worked from in the 1990s was small and unexciting: Arial, Times New Roman, Courier New, and a few others on Windows; Helvetica, Times, and Courier on Mac; Georgia and Verdana once Microsoft distributed them widely. This limitation was not accidental — it was an unintended consequence of the web's original design, which treated font rendering as the operating system's responsibility rather than something web standards needed to address.

Microsoft's "Core fonts for the Web" project (1996–2002) made one meaningful contribution to this era: it commissioned and freely distributed several new typefaces specifically designed for screen legibility. Matthew Carter designed Verdana and Georgia for this project, and both became genuine contributions to screen typography — well-hinted, readable at small sizes, and widely distributed. Verdana's generous x-height and wide letterforms made it unusually readable at 10–12px, the typical text size of web pages in the late 1990s and early 2000s.

CSS2 @font-face and EOT

The CSS2 specification, published by the W3C in May 1998, included the @font-face rule — a mechanism for web pages to reference external font files. Theoretically, this was exactly what the web needed: a standard way to download and use any font in a web page. In practice, implementation was inconsistent, browser support was fragmented, and the feature effectively disappeared from practical use within a few years of its introduction.

The most significant early implementation came from Microsoft. Internet Explorer 4 (1997) and IE 5 (1999) supported @font-face, but exclusively with Microsoft's proprietary EOT (Embedded OpenType) format. EOT was a compressed, DRM-protected version of TrueType or OpenType fonts designed to prevent font piracy. EOT files bound fonts to specific domains using a digital rights management mechanism — an EOT file created for example.com would not load on anotherdomain.com.

Microsoft created the WEFT (Web Embedding Fonts Tool), a Windows desktop application that generated EOT files from installed fonts. Web designers who wanted to use custom fonts on IE had to own the font, install it on Windows, run WEFT, specify the domain the font would be used on, and upload the resulting .eot file alongside their CSS. This process was cumbersome and technically inaccessible to most designers of the era.

More critically, no other browser supported EOT. Netscape, Opera, and the eventually dominant Firefox all ignored it. Microsoft submitted EOT to the W3C for standardization in 2007–2008, but the W3C rejected it in favor of developing a new, open format (which became WOFF). EOT is now deprecated and unsupported in all modern browsers. It represents an instructive example of how proprietary formats fail to become standards even when backed by the dominant market player.

The Dark Ages: sIFR and Cufon

Between approximately 2004 and 2009, web designers who wanted to use custom fonts invented increasingly elaborate workarounds. The most widely adopted were sIFR (Scalable Inman Flash Replacement) and Cufon — both clever hacks that achieved the goal of custom web type while introducing their own significant problems.

sIFR was created by Mike Davidson and refined significantly by developer Mark Wubben starting in 2004. The technique used Adobe Flash to render custom text. A JavaScript file would scan a page for specified HTML elements (typically headings), hide the HTML text by making it invisible, and inject Flash movies in its place. Each Flash movie rendered the same text using a custom font embedded in the SWF file. The result was visually accurate custom type, but the implementation was fragile and slow: Flash had to load, initialize, request dimensions from JavaScript, render text, and report back — a process that often caused visible "Flash of Unstyled Content" delays.

Cufon, created by Simo Kinnunen in 2009, avoided Flash by using a different approach: it pre-converted font outlines into a JavaScript file containing the glyph path data, then rendered text onto HTML5 canvas elements using JavaScript. Cufon was faster than sIFR, worked without Flash, and could handle some body text use cases. However, text rendered via Cufon was not selectable in the normal way, was invisible to screen readers, and created significant JavaScript execution overhead on pages with large amounts of custom-font text.

Both sIFR and Cufon were abandoned rapidly once proper web font support arrived in 2009–2010. Their existence demonstrates the genuine demand for custom web fonts that the standards community had failed to address for over a decade — and the lengths designers would go to in order to escape the typographic limitations of the web-safe era.

Typekit and the Font Service Revolution

In September 2009, Jeffrey Veen, Bryan Mason, Ryan Carver, and Greg Veen launched Typekit — the first practical commercial web font hosting service. Typekit's solution was elegant: rather than requiring web developers to download and self-host fonts (which raised copyright concerns) or trying to standardize a new file format (which required browser adoption), Typekit created a service layer. Type foundries licensed their fonts to Typekit; Typekit served them via JavaScript and CSS to paying subscribers; the technical complexity of cross-browser compatibility was entirely Typekit's problem, not the designer's.

The technical mechanism was straightforward: include a <script> tag from Typekit in the page's <head>, add a CSS class to the <html> element, and reference Typekit-served fonts in @font-face declarations. Typekit's JavaScript detected the browser and served the appropriate font format — EOT for Internet Explorer, TrueType or OpenType for other browsers — and handled font loading events to minimize the Flash of Unstyled Text (FOUT) that had plagued earlier web font implementations.

Typekit demonstrated that there was massive pent-up demand for quality web fonts. Within months of launch, it had secured partnerships with major foundries including Font Bureau, Dalton Maag, Mark Simonson Studio, and eventually Adobe itself. The service grew rapidly and attracted significant attention from the design community as well as larger technology companies. Adobe acquired Typekit in October 2011 for approximately $30 million — a clear signal that web fonts had become a significant business category. Adobe eventually integrated Typekit into Creative Cloud and rebranded it as Adobe Fonts, where it remains available to all Creative Cloud subscribers.

Typekit's success inspired immediate competition. Fonts.com Web Fonts (by Monotype) launched in 2009, Fontdeck launched in 2010, and WebINK, FontFont Web Fonts, and others followed. The subscription web font service model — foundry licenses fonts to service, service delivers to designers — became the standard approach for commercial web font distribution and remains the dominant model for premium typefaces today.

Google Fonts Democratizes Web Typography

Google Fonts launched in May 2010, offering a completely free, open-source font library served from Google's global CDN infrastructure. While Typekit had proven that web fonts were desirable and commercially viable, Google Fonts removed every remaining barrier: no cost, no licensing complexity, no subscription required, no JavaScript dependency (the service worked with a simple CSS link tag), and blazing-fast delivery from Google's CDN with edge servers on every continent.

Google Fonts launched with a modest collection of open-source typefaces but grew its library aggressively by commissioning new typefaces specifically for the project. Key commissions included Roboto (designed by Christian Robertson at Google, 2011), which became Android's default interface font; Open Sans (Steve Matteson, 2011), which became one of the most widely used typefaces on the web; Lato (Lukasz Dziedzic, 2010); and the Noto project — an enormous ongoing effort to develop typefaces covering every Unicode character in every script, addressing the long-standing problem of missing glyphs on multilingual websites.

The impact of Google Fonts on web typography was transformative. It meant that any website — a personal blog, a small nonprofit, a startup with zero budget — could use custom fonts that looked as good as those on premium commercial sites. The playing field was leveled overnight. Google Fonts processes over 70 trillion font file requests annually as of the mid-2020s, serving fonts to an estimated 60 million websites worldwide. Fonts like Roboto, Open Sans, Lato, and Montserrat have become so prevalent on the web that they are effectively the new web-safe fonts — typefaces that users have almost certainly downloaded from Google Fonts for another site and that browsers may serve from cache.

WOFF: The First True Web Font Format

WOFF (Web Open Font Format) was proposed in 2009 by type designers Erik van Blokland and Tal Leming, together with Mozilla engineer Jonathan Kew. WOFF was not a new outline format — it contained existing TrueType or OpenType font data unchanged — but rather a packaging format specifically designed for web delivery. WOFF wrapped existing font tables in a compressed container, reducing file sizes by 40–50% compared to uncompressed TrueType, and added standardized metadata fields for font licensing information.

The design philosophy behind WOFF was intentionally conservative: rather than creating a new font format that would require font conversion tools and introduce compatibility risks, WOFF simply made existing fonts smaller and added a clear web-delivery context. Font foundries could take their existing TrueType and OpenType fonts, pass them through a WOFF compression tool, and the resulting files were suitable for web delivery. This simplicity was critical to rapid adoption.

Browser adoption was swift. Mozilla Firefox added WOFF support in Firefox 3.6 (January 2010). Chrome added support in version 6 (September 2010). Internet Explorer 9 (March 2011) added WOFF support alongside the EOT format it had supported since IE 4. Safari 5.1 (July 2011) completed the major browser matrix. WOFF became a W3C Recommendation on December 13, 2012 — achieving standards status with essentially universal browser support already in place, a rare circumstance in standards development.

WOFF2, developed primarily by Google engineers (Jungshik Shin, Behdad Esfahbod, and others), improved on WOFF's compression by replacing zlib with a modified version of Brotli compression combined with a preprocessing step that restructures glyph outline data into a more compressible form. WOFF2 achieves approximately 30% better compression than WOFF1, and was first implemented in Chrome 36 (July 2014). WOFF2 became a W3C Recommendation in March 2018 and now has 97%+ global browser support. Our dedicated guide covers why WOFF2 was created and how its compression works in detail.

The Modern Era

Today's web font ecosystem is mature, performant, and well-standardized. WOFF2 with its Brotli-based compression is the universal delivery format, supported by all browsers in active use. The long @font-face rule with EOT, SVG, and multiple fallback formats — a fixture of professional CSS from 2010–2016 — has been replaced by a clean two-line declaration: WOFF2 with a WOFF1 fallback for older Safari versions, or simply WOFF2 alone for projects willing to drop IE11 support.

Variable fonts, specified in OpenType 1.8 (September 2016) and supported by all major browsers since 2018, represent the most significant development in web font technology since WOFF. A single variable font file can replace an entire font family, enabling continuous interpolation between defined weight, width, optical size, and custom axes. A variable font for a typeface with six weights and two widths might be 60% the size of the six separate traditional font files while enabling infinite intermediate values.

The font-display CSS property, widely supported since 2018, gives developers precise control over the font loading lifecycle. font-display: swap shows system fallback text immediately while the custom font loads, then swaps in the custom font — preventing the invisible text problem that plagued early web font implementations. font-display: optional allows browsers to skip custom fonts entirely if they cannot be loaded within a brief initial period, prioritizing performance in degraded network conditions.

The journey from the five-font web-safe era to today's typographic freedom took two decades. It required competitive pressure between Microsoft and the open-web community to dislodge EOT, entrepreneurial creativity from Typekit to prove the commercial model, Google's infrastructure and investment to universalize access, and sustained standards work from Mozilla, Google, and the W3C to create a truly open, cross-browser solution. The result is a web where any designer, anywhere, with any budget, can choose from thousands of quality typefaces and deliver them to users with sub-100ms latency. It is one of the web's genuine infrastructure success stories.

Related History Pages

Explore the broader history of font technology that laid the groundwork for modern web fonts.