Could Someone Explain the BASE64 CSS used by font squirrel

Question

I've been using font squirrel to generate web fonts for a while. Usually the CSS it gives is like this:

@font-face {
    font-family: 'sancoale_slsf_norm_regunormRg';
   src: url(sancoaleslabsoft_normregular_macroman/SancoaleSlSfNormRegular-webfont.eot');
    src: url(sancoaleslabsoft_normregular_macroman/SancoaleSlSfNormRegular-webfont.eot?#iefix') format('embedded-opentype'),
         url(sancoaleslabsoft_normregular_macroman/SancoaleSlSfNormRegular-webfont.woff') format('woff'),
         url(sancoaleslabsoft_normregular_macroman/SancoaleSlSfNormRegular-webfont.ttf') format('truetype');
    font-weight: normal;
    font-style: normal;
}

But playing around with generating the WOFFs as base64 the outputted CSS changes to:

 @font-face {
font-family: 'sancoale_slsf_norm_boldnormBd';
src: url('sancoaleslsfnormbold-webfont.eot');
}

@font-face {
font-family: 'sancoale_slsf_norm_boldnormBd';
src: url(data:application/x-font-woff;charset=utf-8;base64,d09 [BLABLABLA] =) format('woff'),
     url('sancoaleslsfnormbold-webfont.ttf') format('truetype');
font-weight: normal;
font-style: normal;

}

Does anyone know why the @font-face declaration is split? - Just interested really!

Answer 1

Base64 is a binary-to-text encoding scheme that represents binary data in an ASCII string format.

Data URI is just a URI scheme that provides a way to include data in-line.

Basically, you're converting the font file into a crazy long string of text that you can paste right in your font-face declaration to replace the font file source link.

The Data URI Scheme is:

data:[<mediatype>][;base64],<data>

The Base 64 source in a @font-face looks like:

src: url(data:application/x-font-woff;charset=utf-8;base64,<your base64 font>) format('woff'),

Font Squirrel's generator provides the .eot file as IE support for Base64 began with version 9 (I think).

I've found this method of font-face to have higher deliverability over Paul Irish's bulletproof method.

Fonts.css
In practice, I throw all my base64 encoded fonts (plus weight variations) inside a fonts.css file. This also includes my icon font - which I use IcoMoon's web app to build and get the base64.

Yeah, base64 adds some bulk and it sure isn't pretty, but throwing them all into a central fonts.css file reduces your requests, prevents FOUC, and seems to do a great job of getting around stupid aggressive firewalls that block font file types as default.

I actually wrote a little post on this a while back.

Answer 2

My guess is that this is a workaround for the differing data URI support among internet explorer versions. IE 6-7 have no support, IE 8 only supports some elements and only up to 32KB, and IE9+ supposedly works without issue. More info on Data URI support can be found over at Wikipedia and caniuse . The 'base64 CSS' option at font squirrel uses data URI encoding.