The @Font-Face Firefox Fiasco

In Firefox, web fonts must be on the same domain as the page using them unless you’ve updated HTTP access controls to allow for cross-origin resource sharing. It seems Firefox is the only browser to adhere to the specification in this regard.

So, you’re building out an awesome Tumblr theme and notice fonts aren’t rendering in Firefox because they’re hosted on a different domain. Changing the access controls is hard and can’t be done on sites like Tumblr. What do you do?

Base64 encode them.

Yes, it will inflate the size of the CSS. But you’re eliminating a request. A tradeoff I can live with. Here’s how to do it in two easy steps.

  1. Base64 encode the font file

    cat /Volumes/Entypo/@font-face/entypo-webfont.ttf openssl enc -base64 tr -d ‘\n’ pbcopy
  2. Paste the data into the stylesheet

    @font-face {

    src: url(‘data:font/opentype;base64,« BASE64 ENCODED DATA HERE »’) format(‘truetype’);


Further reading

  • Data URIs on
  • font-face": on Mozilla Developer Network
Photo of Brian Ryckbost

Brian is a veteran software developer that pairs his technical vision with an entrepreneurial mind to drive the company forward.


Post a Comment

(optional — will be included as a link.)
  1. OpenSSL? Oy! What’s wrong with /usr/bin/base64?
    July 05, 2012 at 21:44 PM
  2. @anon: absolutely nothing, I just knew about openssl. Thanks for the tip though

    July 06, 2012 at 1:57 AM
  3. I believe Firefox is not the only browser to do this — IE9 and IE10 also impose the same-origin restriction.
    Robert O'Callahan
    July 06, 2012 at 2:28 AM
  4. Ha, was just dealing with this today.

    Two things:

    1) You can do this automatically in the Rails asset pipeline by calling asset_data_uri.  Makes things nice and clean from a dev perspective.

    2) IE 7 & 8 (not 9) will choke completely on the @font-face (and maybe the whole CSS file)–they have a 32k limit on data urls. Splitting out a separate IE fonts CSS gets around this.
    E.J. Dyksen
    August 21, 2012 at 7:18 AM
  5. @E.J.: Whoa, I had no idea about asset_data_uri. Thanks for pointing that out!

    August 21, 2012 at 12:28 PM
  6. I can live with the trade off too. thanks for a great post
    March 03, 2013 at 23:31 PM
  7. Oh thank you so much, I’d despaired of ever finding a solution to this problem. I can’t tell you how relieved I am to finally find a fix for this, but thank you for taking the time to write this.
    April 12, 2013 at 6:12 AM
  8. THANK YOU SO MUCH! I’m working with a CMS that publishes sites to a staging server, then transfers to the live server. My fonts were stored on the live server, and I couldn’t figure out why things wouldn’t display correctly on the staging server. Your opening paragraph just solved all my problems. Big DUH. Thanks!

    September 12, 2013 at 20:23 PM