Introducing @font-face

@font-face, a feature that has been talked about since 1998, is finally here! Nope, it’s not a twitter ID. @font-face is a component of CSS3 that allows the designer/developer of a web site to include fonts that are not installed on the user’s computer.

Web site design has been hampered by the limited number of fonts available to most clients. Designers have been using image replacement and methods such as sIFR and Cufón to make up for limited choices in typography. If designers want to ensure their designs look almost identical for all users, they’re limited to the few font sources that are known to be installed on almost all computers.

Wait. Let’s make that sentence past tense. “If designers wanted to ensure their designs looked almost identical for all users, they were limited to the few font sources that were known to be installed on almost all computers.” There is now a solution! We are no longer limited to Arial, Helvetica, Georgia, sans-serif!

@font-face enables the developer/designer to use any (with legal limits) font family on a web site by downloading the font file onto to client computer, and then declaring it as you would any font-family.

@font-face has been supported to some extent for years. It was in the CSS2 specifications. Microsoft implemented @font-face in Internet Explorer 4, but, as is typical of Microsoft, used a proprietary font format format (EOT). Due to copyright and legal issues, @font-face was dropped in the CSS2.1 specification. But, now it’s back. And it’s supported. It is expected to be in the W3C CSS3 specification when that finally gets finalized. Assuming that it will be in the CSS3 specification, all other browsers (Opera, Webkit, Mozilla) support @font-face with an implementation that supports formats like TTF and OTF. IE continues to support only the EOT format. Webkit for mobile (think ‘iPhone’) supports only SVG.

There are two steps to using the font of your choosing in your CSS file: 1) you must first declare your intention to import a font by using the @font-family syntax, telling the browser how you are going to reference the font (what name you will use to refer to the font), where to download the file, and what format the font is in. 2) You then have to include the font name in a font-family declaration, just as you would include Helvetica, Georgia or "Times New Roman".

The syntax for the @font-face implementation is:

@font-face {
  font-family: yourNameForTheFont; /* required */
  src: source;						/* required */
  font-weight: weight;				/* optional */
  font-style: style;				/* optional */

The source takes both the file name source and the format type. The source can take several formats. In addition, you can declare more than one source. If the browser doesn’t find the first source, it will go for the next source, and so on, until it either finds a source, or it runs out of sources. As withe all CSS file references, the URL should be a relative or absolute path. If relative, it should be relative to the CSS file.

Example formats include:

@face-font {
     font-family: 'My Font Name'
     src: url('../fonts/makeUpSomethingElse.eot');
     src: local('Edwardian Script ITC'),
          url('../fonts/EdwrdScrpItc') format('opentype'),
          url('../fonts/GaelicWimsy') format('svg'),

It is not enough to declare the creation of the font. You have to use it. Once you’ve downloaded the font and assigned it a font-family name, you can use that name as you would any other font name as the value of the font-family property

.mySelector {
    font-family: 'My Font Name', Arial, Helvetica, sans-serif;

Hurdles to consider when considering implementing @font-face

Yes, @font-face is finally supported in all browsers. But implementation isn’t so simple. There are several hurdles to consider and overcome to ensure that your implementation works, looks good, provides a good user experience and is all legal:

  1. Different formats for different rendering engines and devices

    While all browsers support @font-face to some extent, we still have browser support and compatibility issues to contend with. Most modern browsers support both the TTF and the OTF format. Firefox 3.6+ supports WOFF, a web-only font format. As mentioned earlier, Safari for iPhone only accepts the SVG format. And, we’re stuck with IE only accepting the EOT file format. There are also some rendering differences in those various formats.

  2. Huge file sizes

    Though not exactly a hurdle to implementation, font file sizes are a concern to keep in mind when it comes to user experience. Font files can be huge. Some formats are way larger than others. An embedded font means you have to download to use. A source with simple lines, like Arial or Helvetica, may weigh about 16 – 20kB. More complex fonts, with complex strokes, that you’re more likely to want to include, may be over 200kB in file weight. And remember that you may need to download the bold, italic and bold-italic versions of your font


  3. Delay in rendering

    Depending on the file size of your font file, and whether the font is already cached in the client browser, embedding fonts can cause the browser to rewrite the page. In our above code example, the page may render with Arial, Helvetica or other sans-serif font, then redraw the page when the font file is successfully downloaded.

    Embedded fonts do not always show immediately . The delay in rendering depends on the browser and whether the fonts have been loaded in cache or not. As such, text with embedded fonts as the font family may take a moment to display or display first with a system font, as the embedded font is loaded.

  4. Legal implications of font usage

    To allow the downloading of a font, you must have a web-font license for the font! It’s not enough that you purchased a font and have a right to use it for personal use with any application on your own computer, including production of print material for distribution. You have to have a license or other permission to distribute the font file itself, since, in effect, this is what you are doing with @font-face. Check the Web site you are downloading or purchasing the font from, or the documentation that comes with the font. Only embed fonts that have the appropriate licenses.

Not a hurdle, but something to be aware of:

For security reasons, some browsers (like Safari) ask the users if they are alright with downloading fonts from the internet – so that is a user experience consideration as well.

Tips for @Font-Face

  1. Fallbacks for browsers that don’t support @font-face: Depending on what font you choose, your default fonts may not look right at that font-size. Using Modernizr can be helpful in controlling the appearance when @font-face is not supported. For example, if you use an expanded font, such as Impact, or a very condensed font, fallback fonts such as Arial or Verdana can break your layout. With Mondernizr you can tell the browser to user larger or smaller font-sized if the browser doesn’t support @font-face, or even tell the browser to user sIFR, Cufon or any image replacement method for non supporting browsers only.

    .fontface  h1 {
      font: 16px/24px 'My Font Name', Arial, Helvetica, sans-serif;
    .no-fontface  h1 {/*
      Rules for sIFR/Cufon or for an image replacement method of your choice, or a better font size for Arial and Helvetica.
    .no-fontface  h1#myID {
    	background-image: url(imagereplacement);
  2. Include default fonts in every font declaration: Do not forget to include default fonts in your font-family declaration. Puts the declared font-family name of your downloaded @font-face embedded source, and follow it with the default alternatives (arial, helvetica, sans-serif).

  3. Include font variants only if needed, but do include them if used: Check which variants of the font you need for your site. Include the italic, bold and italic bold font if you are going to use it. But don’t included more than you have to! You don’t want the user to have to wait for the download of a font if that font is going to be unused.
  4. Check out the following resources:

Published by

Estelle Weyl

My name is Estelle Weyl. I an open web evangelist and community engineer. I'm a consulting web developer, writing technical books with O'Reilly, running frontend workshops, and speaking about web development, performance, and other fun stuff all over the world. If you have any recommendations on topics for me to hit, please let me know via @estellevw.