See all Insights

Why @Font-Face Will Replace sIFR

A year ago, I wrote a post expressing my wish that 2010 would be the year of better web fonts and, as the year progressed, I got my wish. As we enter 2011, I believe it’s time to say goodbye to sIFR font replacement and say hello to @font-face font embedding.


Scalable Inman Flash Replacement (sIFR), a method for inserting rich typography into web pages without sacrificing accessibility, search engine friendliness, or markup semantics, was developed in 2005 by Mike Davidson and Mark Wubben. Since 2006, Newfangled has been recommending sIFR to our clients as an alternative to the few web-safe fonts available for browsers. Although it’s been a better solution than using graphics as a replacement for custom headlines, sIFR has grown long in the tooth and been up-staged by a more efficient and elegant method known as @font-face font embedding.

sIFR uses a combination of JavaScript and Flash to “replace” a web-safe font (such as Arial), with a custom font like Garamond. A Flash file is created with the custom font embedded. The resulting .swf file is then served up via javascript to a web page with the custom font replacing the original browser font (this is an over-simplified explanation; here’s the full geek version if you need it).

Actually, the ability to view embedded fonts in a browser has been around longer than sIFR technology but remained unused because of font licensing issues. There was no easy way to protect embedded fonts from being downloaded from a website, much the same way web images can be downloaded by right-clicking with your mouse and selecting, “Save Image As…” from the pop-up menu.

The Rise of @font-face

In 2008, a company called Typekit began developing a platform for serving up rich typography on the web using font embedding and licensing fonts on a subscription basis. You can read more about Typekit in my January 2010 post. Since then, several websites have sprung up offering similar services. Typekit, Typotheque and Kernest enable webpages to use the @font-face rule to access font files stored on a global network of secure servers. Other sites like Font Squirrel and Fontspring offer free fonts with @font-face code that you can download and include in your site’s CSS.

The main advantage that @font-face embedding has over sIFR is that it doesn’t use any third-party technology such as javascript or Flash to serve up the fonts; instead it uses native CSS to provide nice, clean code. Newfangled’s experience with sIFR over the years has been mixed at best. It can be buggy and slow to load. If a user has javascript turned off in their browser or doesn’t have the Flash plug-in, sIFR fonts won’t load and the browser defaults to a web-safe font. Ad blockers will sometimes replace the sIFR font with a gray square.

Perhaps in the future we’ll be hearing about a new font technology that will replace @font-face but, until then, it’s the best way to serve up custom fonts on a website and gives web designers a much broader typographic palette.

Related Posts