F Blog Home

The New Bulletproof @Font-Face Syntax

Updated: April 21, 2011 10:49 AM EST

Since the beginning of the 'webfont revolution' we've relied on somewhat hacky @font-face declarations to get webfonts loading cross-browser. Could there be a better way? One that's clear and compatible with future browsers?

Short history

In September 2009, Paul Irish came up with the Bulletproof syntax for writing the @font-face declaration. It was compact and worked across all browsers at the time. Recent, growing complaints that fonts weren't loading in Android, led me to recommended the Mo' Bulletproofer syntax devised by Richard Fink instead. Unfortunately Mo' Bulletproofer requires double declarations. Defining each font twice in the CSS is cumbersome, so I looked for a better solution.

The “Fontspring @Font-Face Syntax”

The code should have been clean, clear and simple all along. Finally, it is:

@font-face {
	font-family: 'MyFontFamily';
	src: url('myfont-webfont.eot?#iefix') format('embedded-opentype'), 
	     url('myfont-webfont.woff') format('woff'), 
	     url('myfont-webfont.ttf')  format('truetype'),
	     url('myfont-webfont.svg#svgFontName') format('svg');

What? I don't get it.

The hack trick that makes this work is the '?' following the EOT filename. Seriously.

How it works

Internet Explorer <9 has a bug in the parser for the src attribute. If you include more than one font format in the src, IE fails to load it and reports a 404 error. The reason is that IE attempts to load as a file everything between the opening parenthesis all the way to the very last closing parenthesis. To deal with that wrong behavior, you merely declare the EOT first and append a single question mark. The question mark fools IE into thinking the rest of the string is a query string and loads just the EOT file. The other browsers follow the spec and select the format they need based on the src cascade and the format hint.

Browser compatibility

Safari 5.03, IE 6-9, Firefox 3.6-4, Chrome 8, iOS 3.2-4.2, Android 2.2-2.3, Opera 11

What about data uri fonts?

You can use this syntax as well to embed your fonts into a stylesheet. For it to work does require two declarations however. But if you are going this route, what is an extra declaration? Note that the format hint for the EOT needs to be 'embedded-opentype.'

@font-face {
	font-family: 'MyFontFamily';
	src: url('myfont-webfont.eot?') format('embedded-opentype');
@font-face {
  font-family: 'MyFontFamily';
    url(data:font/truetype;charset=utf-8;base64,BASE64_ENCODED_DATA_HERE)  format('truetype'),
    url(data:font/woff;charset=utf-8;base64,BASE64_ENCODED_DATA_HERE)  format('woff'),
    url('myfont-webfont.svg#svgFontName') format('svg');

Albert Ward offered to translate this post to Bulgarian

Update 1 - Feb 3, 2011

The CSSNinja made a great observation about how to get IE9 to take a WOFF instead of the EOT. He suggested adding a hash to the format hint of the EOT. This works because IE9 doesn't recognize the format hint '#embedded-opentype.' So I modified the syntax to reflect his finding. I changed the format hint from 'embedded-opentype' to 'eot' which IE9 doesn't understand either and therefore moves on to the WOFF. We've reverted back to the correct format hint for eot, format('embedded-opentype') due to issues with serving on IIS. See this post for details.

Update 2 - Feb 4, 2011

IE was failing to load webfonts if the page was loaded locally. Turns out that IE prefers the '?' question mark character. The code has been updated to reflect this. Originally this post lauded the magical '#' hash. Hat tip to Chris Neale for the idea.

Update 3 - Feb 21, 2011

In response to this syntax not working in IE9 Compatibility modes (as well as an extended conversation with Microsoft) we've updated the syntax slightly. The revision adds redundancy, but further bulletproofs the method. Please see our separate post about this here.

Update 4 - April 21, 2011

When this syntax is used on an IIS server, IE9 users may not see the font. This can be solved in two ways. 1) Add the WOFF format to the list of MIME types. or 2) change the format('eot') portion to format('embedded-opentype'). Either one will solve issues with IE9.


Andrew Staffell

great work - will start testing straight away.

February 3, 2011 at 12:33 PM

Richard Fink


My hat is off to you for thinking of a hash mark!
Paul Irish reports that his recent testing of IE9 was done on Preview 7. Since an RC version of IE9 is expected in a few days, judgment is premature, I think, until we are all hands-on with that, at least.
As for the double-download in IE9 that Paul reported, that's easily fixed with the first declaration in Mo' Bulletproofer being within conditional comments - conditional comments which will probably be pre-existing on the web page, anyway - making it pretty convenient to cordon off the "less than" IE9 rules.

February 3, 2011 at 12:34 PM


Cool. :D The simplest solutions are the bestest.

February 3, 2011 at 12:34 PM

Erik Vorhes

I can confirm that this syntax also works in Internet Explorer 6 and Opera 11. Beautiful!

February 3, 2011 at 12:36 PM


Very clever!

February 3, 2011 at 12:41 PM

Paul Irish

Nailed it.

February 3, 2011 at 12:41 PM


I wouldn't say this new magical syntax is facepalm-simple, but it is remarkably elegant considering the wealth of stuff it distills.

Three thumbs up.

February 3, 2011 at 12:49 PM

Niki Brown

Shazam! Thanks for all the hard work you do! The web is a much nicer place now :)

February 3, 2011 at 01:03 PM

Christopher Beckwith

Bravo, updating my code as we speak...well...type.

February 3, 2011 at 01:11 PM


Great work guys! Thanks so much for pushing the industry!

"Could there a better way?" = "Could there be a better way?"

February 3, 2011 at 01:25 PM

Peter Gasston

Nice one! How on earth did you think of that?

February 3, 2011 at 01:26 PM

Ethan Dunham

@Spencer - Thanks! And typo fixed.

@Peter - Trial and error and more error. Finally occurred to me after staring at the error logs output by IE.

February 3, 2011 at 01:31 PM

Jonathan Snook

Well done, Ethan! Absolutely fabulous!

February 3, 2011 at 01:45 PM

Stephanie (Sullivan) Rewis

Awesome work! I was just working on this yesterday. I shall implement your syntax right away! Thank you. :)

February 3, 2011 at 01:54 PM

Marius Ciobotaru

Great job.

February 3, 2011 at 01:57 PM

Raphael Essoo-Snowdon

Brilliant. Just brilliant!

February 3, 2011 at 02:03 PM

Jason Cranford Teague


February 3, 2011 at 02:07 PM

Ethan Dunham

Thanks all. I am merely standing on the shoulders of others.

February 3, 2011 at 02:08 PM


Truly brilliant. And I wouldn't even call it a hack!

February 3, 2011 at 02:10 PM

Jean-Philippe Sirois

Great discovery!

I’ve Already updated my current project Font-Face CSS.

This should be part of Font Squirrel generator too.


February 3, 2011 at 02:15 PM

Richard Fink

I don't know about anyone else, but I'm hoping this is IT.
With some variation of the "no-404" double declaration hack relegated to special cases where LESS THAN IE9 CSS rules must be separated from the standard compliant rules because of the other ways in which IE6,7, and 8 differ.
In testing: test with the URL inside double quotes, single quotes, and with no quotes.
If the font displays, don't accept that as proof of anything - make sure you use Fiddler or some other app or method to make sure there is no 404 and that ONLY the font file you expect is downloading.
Looking forward to seeing how this tests out.

February 3, 2011 at 02:18 PM

Denise Jacobs

Teaching this in my next CSS3 training. Nicely done! I've always disliked the double declaration -- too messy.

February 3, 2011 at 02:26 PM

Matt Wiebe

Well done Ethan. Lovely.

I made a test page to show that, at the very least, IE is using the EOT font and not the WOFF: http://somadesign.ca/demos/IE9-WOFF-Test/bulletproofest.html That won't say anything about double downloads for IE, but I'm guessing we'll be sure of that soon enough.

February 3, 2011 at 02:27 PM


simply brilliant .. thanks man :)

February 3, 2011 at 02:32 PM

Zoltan Hawryluk

Awesome with a capital AWE! :-) Going to test further, but looks <tony_the_tiger>G-r-r-r-r-EAT</tony_the_tiger> so far. Hats off to you!

February 3, 2011 at 02:35 PM

Ethan Dunham

It should be noted that IE9 will always download the EOT instead of the WOFF using this syntax. This shouldn't be much of an issue as we will soon be offering compressed EOTs as well.

February 3, 2011 at 02:38 PM



February 3, 2011 at 02:40 PM

Thijs van der Vossen

Lovely! You don’t know how happy this makes me. :)

February 3, 2011 at 03:02 PM

Ryan Corradini

Brilliant. Excellent work.

February 3, 2011 at 03:03 PM


This is effing awesome. It's better than font-squirrel's latest implementation which isolates IE and other browsers loading into two sections. Well done!

February 3, 2011 at 03:19 PM


yipee! great work Ethan, thanks for making life easier for the rest of us!

February 3, 2011 at 03:19 PM

Stephanie (Sullivan) Rewis

I've just tested a Galaxy Tab, HTC Desire HD, iPad and iPhone (since everyone else has tested browsers). I'm thrilled to now have my fonts properly appearing in my Android devices (and iOS is still fine).

February 3, 2011 at 03:30 PM

Erica J

Strikingly clever! Beautiful work, Ethan!

February 3, 2011 at 03:45 PM

Brian Klepper

Amazingly simple solution. Thanks for this 'Final' solution :)

February 3, 2011 at 03:58 PM


Fantastic work my friend. Sure beats having 2 stylesheets and using conditional css. Thanks :)

February 3, 2011 at 04:04 PM

Andreas Papula

Thx for your work!
I'll use this in upcoming Projects (and update my existing Projects asap).

February 3, 2011 at 04:09 PM


It is working with Opera 11.01. You can add it to your list.

February 3, 2011 at 04:11 PM


HMmm, I'm not sure what I did wrong. @font-face was working okay for me on most browsers, i changed it to this and broke Chrome, Safari and FF on Mac. Probably user error. I'll see what I can figure out.

I wonder if it's because I have it in a /fonts/ directory?

February 3, 2011 at 04:15 PM


omg! just in time :)

February 3, 2011 at 04:18 PM

Ethan Dunham

@darcy - No, not likely. Give us a URL to peek at...

February 3, 2011 at 04:24 PM

Kirk Franklin

Is the #webfontFqDaNIX6 necessary after the svg filename?

February 3, 2011 at 04:34 PM


Confirming it was indeed, operator error. ;)

February 3, 2011 at 04:34 PM

Ethan Dunham

@kirk - No and yes. It is confusing. An SVG file requires a hash '#' along with the name of the font inside the actual SVG file. Will update my example.

February 3, 2011 at 04:42 PM


Anyone know whether there are plans for Firefox to allow fonts hosted away from the main domain? Our lovely fonts are wasted on FF users, since I've got them on Amazon S3 at the moment...

February 3, 2011 at 04:52 PM

Paul Irish

Geoff, this is totally doable. (Also IE9 has the same "feature" :)

https://developer.mozilla.org/En/HTTP_Access_Control describes the process.

In apache, the config for cross-domain font serving looks like this: https://github.com/paulirish/html5-boilerplate/blob/1733f/.htaccess#L57-69

You should be able to declare this header for your AWS-hosted assets.

February 3, 2011 at 05:17 PM


Wow. You are a life saver. THANK YOU!

February 3, 2011 at 05:20 PM

Kirk Franklin

Cool, thanks, that makes more sense.

February 3, 2011 at 05:58 PM


Nice work, bloody good solution. I adjusted it ever so slightly so now in IE9 it will download the woff font rather than the EOT with all the same benefits. Take a look http://www.thecssninja.com/demo/css_fontface/

February 3, 2011 at 06:15 PM


Hurrah, I was a bit worried that even Mo Bulletproofer was too hacky to be forward-compatible. With any luck this one will stick.

^^ @Ryan - nice one with the IE 9 friendly syntax, I will check that out, I would much rather support the woff format over eot :)

February 3, 2011 at 07:02 PM

Ethan Kramer

How do you know what goes after the hashtag when embedding the font as an svg

February 3, 2011 at 07:33 PM


Very cool, thanks Ethan!

@Jean-Philippe Sirois - I agree, this needs to be added to the Font Squirrel Generator or even Ryan's version that serve's up the woff to ie9.

@Ryan - Interesting, more power to you for serving up the woff version in IE9!

February 3, 2011 at 07:40 PM


Correct me if I'm wrong, but I couldn't get the new syntax to work on a test page locally in IE7. It wasn't until I uploaded it to a server and accessed it through the web that it worked.

February 3, 2011 at 08:12 PM



But don't work on Midori Webkit Browser

February 3, 2011 at 09:26 PM

Aaron James Young

@Jacobo - I'm using Jumanji, another Gtk-webkit browser, and the @font-face font seems to show just fine, so I would expect it to work in Midori as well. Maybe you have a typo? I've got a quick demo here: http://dl.dropbox.com/u/6605310/fontface/demo.html - it should show Airstream, a kind of retro scripty font.

February 3, 2011 at 09:36 PM

Joss Crowcroft

Yes yes yes YES!

The hash is a stroke of genius. Shame though as I really liked the smiley face in the old syntax...

February 3, 2011 at 09:49 PM

Joss Crowcroft

PS. Can we petition FontSquirrel to update their @font-face syntax for the packaged downloads?

February 3, 2011 at 09:50 PM

Ethan Dunham

This code has already been integrated into Font Squirrel kits and the Generator. Thanks!

February 3, 2011 at 09:54 PM


Nice job getting rid of the second hash eot looks much better! However I thought if that works why not bring back the smiley face. Check it http://www.thecssninja.com/demo/css_fontface/

February 3, 2011 at 10:35 PM

Andrew J. Leer

I just noticed the font wasn't loaded testing a site I am building on Android today thanks for the hard work that went into looking into this!

February 3, 2011 at 11:16 PM

Stephen Clark

Fantastic! This is a great fix. Been struggling with @font-face compatibility on some browsers but this seems to work across all of them...as advertised!! Great work!

February 3, 2011 at 11:20 PM


segue: is this cool to use for different fonts? u know how you have to declare font-x as default and font-x-bold as bold...anyone checked? i'm going to after this. just wondering. great find!

February 4, 2011 at 12:29 AM


lovin it

February 4, 2011 at 03:55 AM


Sounds rock-solid. Can't wait for the major font vendors to implement it! Will have to give it a go.

February 4, 2011 at 04:25 AM

Jake Archibald

Probably worth mentioning that the @font-face declaration should go in a style element on each page, BEFORE any references to external stylesheets, BEFORE any script elements (inline or external). Otherwise IE will block the whole page rendering while the font(s) download.

February 4, 2011 at 04:27 AM


Ahh nice, this is great news! Finally fonts on the web are maturing.

February 4, 2011 at 04:34 AM

Berlin Pictures

Simply clever, thanks again.

February 4, 2011 at 04:39 AM

Martin Broos

Thanks for this solution , works great but i found one problem.

When i use @font-face in chrome on my windows pc it doens't load when i use text-shadow and / or text rotation. Don't think this has something to do with this fix but rather about how chrome on windows loads its fonts. But maybe you know a fix?


February 4, 2011 at 08:08 AM


OMG! Thanks!
I was looking for a such cross-platform solution for quite some time.
And voila - it just works!

February 4, 2011 at 08:21 AM

Richard Fink

I sent a note over to Garrick Van Buren at the free font site Kernest which is currently serving upwards of 200,000 fonts a day.
He implemented it immediately.

February 4, 2011 at 08:38 AM

Jose Guillen

I don't know why but I've tried this code and also another codes and I can't embed fonts in IE I'm starting to hate my life because of this... if somebody can help me I will appreciated it!

Note: My English is not the best so... xD

February 4, 2011 at 11:13 AM

James Williamson

Great work. This is why I love web development. Everyone works, everyone shared, everyone benefits. Thanks for working (and testing) through this.

February 4, 2011 at 11:20 AM

Ethan Dunham

@riskybiz247 - You are absolutely correct. We've found a solution to that...

February 4, 2011 at 02:41 PM

Ethan Dunham

The solution is to use a question mark instead of a hash mark. This fixes the IE local-load issue.

February 4, 2011 at 02:56 PM

Aaron Peters


EOT files can be inlined base64 encoded too, remember?

February 4, 2011 at 03:49 PM


i dont like this it ......

February 4, 2011 at 11:44 PM

Jonathan Rascher

Very cool! I've just been playing around with @font-face (using free fonts from Font Squirrel as well as one I bought from Fontspring), and I must say this new syntax seems much nicer.

February 5, 2011 at 12:31 AM

luciano mammino

Cool tips :) very well!

February 5, 2011 at 06:54 PM


cool and without the ugly smile

February 6, 2011 at 02:48 AM

Chris Hiester

Is this supposed to work with the font I just purchased from Fontspring? Not working for me at http://tinpanvalley.com/terra-studio/splash.php (fonts still looking totally jaggy on Windows/Firefox and IE)

February 6, 2011 at 02:21 PM


I tried the ? instead of # for IE and local (file://) files, and no joy. :-(

Otherwise, working well!

February 7, 2011 at 09:48 AM

Ethan Dunham

@Chris H. - Rendering issues are not related to CSS syntax. What you see is what all of us are struggling with-- Windows text rendering. To get that right is extremely difficult. We feel our solution gets pretty close.

@gary - What version of IE?

February 7, 2011 at 12:38 PM


very simple, but this very beautuful.

February 7, 2011 at 11:09 PM

Thomas Deceuninck

Great fix but doesn't seem to work on Chrome (9.0.597.84) here.
My fonts are replaced with some Times like serif font which means it even ignores my Helvetica fallback.
Anyone else with this issue ?

February 8, 2011 at 03:23 AM



Wam BAM!

February 8, 2011 at 06:11 AM

Ethan Dunham

@Thomas - Just tested Mac Chrome (9.0.597.84) for both local (file://) and remote (http://) and works fine. Post a URL if you want us to take a look.

February 8, 2011 at 09:36 AM


there are some bugs in opera 11, if pathname to the files contain russian symbols. just replace it by latin, and ... profit! :)

February 8, 2011 at 11:15 AM


It was for IE8 and IE8-rendering-as-IE7.

February 8, 2011 at 11:40 AM

Ethan Dunham

@Gary - Hmm, you seem to be the only one. Post or email me a URL so we can debug.

February 8, 2011 at 04:07 PM

Phil Wareham

@Thomas - I think the Times font is a bug in that build of Chrome, not anything to do with this @font-face snippet. It&#39;s doing the same render bug on my site and also bbc.co.uk where it should be displaying Verdana.

February 9, 2011 at 10:33 AM



Before, I've put a font-weight to my @fontface to declare which font should be used.
(font-weight:bold; for bold.otf, font-weight:lighter; for light.otf)

This doesn't work with your new sytax at all.. Is there a solution for this problem?

February 9, 2011 at 11:47 AM

Ethan Dunham

@Toby- Working perfectly for me. The new syntax should have no bearing on this at all. Please post a URL so we can diagnose the problem.

February 9, 2011 at 03:31 PM

Thomas Deceuninck

@Ethan and @Phil, tnx for checking.
I'm testing this website on a MAMP local, but I'll check again when I put it on a testserver.

February 11, 2011 at 05:15 AM

Mark Steggles

Anyone having problems in IE9 rc1? It's not working for me in rc1 but it worked in the beta :/

February 11, 2011 at 08:26 AM

Ethan Dunham

@Mark - The syntax works fine in IE9 RC1 but it does fail in IE9's compatibility modes. The compat. modes seem to be choking on the format() hint.

February 11, 2011 at 08:41 AM

James Likeness

Thanks a billion times a billion for this! Seems to be working a treat for me. The only issue I'm seeing is that Safari seems to ignore font-style tag when it's using @font-face. In my test page that I set up for it, every browser seems to make the sub-head of the page italic except Safari:


February 11, 2011 at 04:18 PM

Ethan Dunham

@James - Safari is actually doing the right thing. Since you did not specify an italic font in any @font-face declaration, it doesn't know what to do with it.

February 11, 2011 at 04:24 PM

James Likeness

@Ethan - Oh okay, cool. How would I go about specifying an italic font that the browser would know to use when you use the font-style: italic tag?

February 11, 2011 at 04:51 PM


Thanks for this! Bookmarked and Tweeted!

February 12, 2011 at 12:53 PM

Mark Steggles

@Ethan - I checked the page and the browser mode is IE9 and the document mode is IE9 Standards.

If I change the browser mode to IE9 Compatibility view then it works but it does not work in IE9 mode.

February 13, 2011 at 08:51 AM

Mark Steggles

The page is www.greataupair.com if you want to take a look.

February 13, 2011 at 08:52 AM

Ethan Dunham

@Mark - Your problem is that IE9, like FF requires font assets to be located on the exact same domain as the site. This includes sub-domains. Also, it appears you are using Mo Bulletproofer and not our new syntax.

February 14, 2011 at 04:29 PM


Not working for me. I had the Smiley face solution and that was working, but since this seems to be a cleaner way to do it, I switched and it is not working for me. Can anyone help?

Here is the link:

Thanks in advance

February 19, 2011 at 04:49 PM


Never mind. I removed a comma by accident when taking out the smiley face fix and that broke the code.

Working beautifully.

You guys rock!!

February 19, 2011 at 04:56 PM


IE9 still doesn't seem to work for me with this new format.

Here's the link:

February 21, 2011 at 12:01 PM

Ethan Dunham

@MB - Since you are serving from IIS, make sure you add WOFF and SVG to your MIME types. That should fix your problem.

February 21, 2011 at 12:39 PM


Wow, great, Worked in all browser except IE (7/8/9). and it's been half a day i've been trying to understand what's the mistake i made, must be a silly one? It would be very kind if you can take a look at the this URL an point me to the right direction

Thanks for the great resource.


Ethan: This was a problem with the font, not the syntax. FYI.

February 22, 2011 at 10:00 AM


@Ethan - That did the trick! Thank you for your help.

February 22, 2011 at 12:02 PM

Brent Lagerman

great job, I was wondering what that ? was when I was downloading font kitsk from font-squirrel recently goodbye smiley! :(

February 23, 2011 at 12:04 AM


Thx! Finally we can get rid of arial, times, verdana and specially COMIC SANS! :D

February 23, 2011 at 03:39 AM


Thank you! Works well as far as I have tested it!

February 23, 2011 at 07:17 AM


Why no option to use a local copy if it exist, would that not speed up the page load (less data transferred) ?

March 5, 2011 at 01:35 AM

Ethan Dunham

@foguebfl - local() crashes Android.

March 7, 2011 at 04:37 PM


Is there any additional load time issues for mobile based sites?

I've never used this technique, did play with the Google Font API, just curious the pros and cons of this vs. Google

March 8, 2011 at 08:06 PM

Ethan Dunham

@Chris - I would assume this would load the same or faster since there is no server on the backend sniffing referrers and processing your request.

March 9, 2011 at 02:41 PM


i'm getting mad, i think i made all that i can make but doesn't work

it works on IE but not in Firefox

so, please if you can, would contact me to try solve the problem, this is an awesome thing to use typos that can't be supported in other ways

March 11, 2011 at 06:40 AM

Ethan Dunham

@Kaze-chan - The syntax is likely not related to your problem. More probable: You are using absolute URLs, or your site is a subdomain. Firefox doesn't allow fonts to be loaded from a domain that is different from the one you are "calling" it from.

March 11, 2011 at 10:36 AM


nice work! thx

March 11, 2011 at 10:44 AM


@Ethan thanks for the info. I'm going to play around with this.

March 12, 2011 at 08:54 AM


Finally i have solve my problem, but don't know how O.O

to make it work i have only need to put this:
@font-face {
font-family: 'HarlowSolid';
src: url('harlowsi-webfont.eot?') format('eot'),
url('harlowsi-webfont.woff') format('woff'),
url('harlowsi-webfont.ttf') format('truetype'),
url('harlowsi-webfont.svg#harlowsi-webfont') format('svg');

and the name in the font-family of desired part, but nothing more like the file said (for example of attaching the .css file)

anyway, thanks for your time and help

March 14, 2011 at 02:34 PM

Ethan Dunham

@kaze-chan - I can't tell from your comment if everything is working for you now. Sounds like it!?

March 14, 2011 at 03:17 PM

Antonio Felix

I bet you guys don't know how much of my life you saved with this article. Epic win, really.

March 15, 2011 at 01:44 PM


I love @font! I have read a lot about it recently and try to implement it in my new websites. Thanks a lot for this info!

I am not sure whether my question fits here well, but I am looking for a solution to the problem that webfonts vary in size (both height and width) compared to the well known (and boring...) standard fonts like Verdana, Arial etc.

When the @font cannot be loaded because of i.e. an old browser, the font falls back to the standard (sans-)serif font-family specified. Sometimes the difference in size is so big that it really looks awfull when the standard (sans-)serif font is loaded.

How can you overcome this problem?
Is there a way to specify a font-size for each font-family?

Thanks for your help.

March 17, 2011 at 08:02 AM


@font is exactly what i've been needing however I'm having trouble getting it to work. I thought I had everything installed correctly but my custom font isn't appearing on computers that do not already have the font installed. What might I be missing?

The site is JanaeWorld.com ...the nav li items should be a custom font.

Thanks so much for your help and for this software!

March 18, 2011 at 01:52 AM


Hiya, I'm trying to get around Firefox's cross-domain @font-face issue, so I've encoded two ttfs as base64 and embedded them in the css (itself embedded in the html). As far as I can tell I've used your code above exactly, but it doesn't work.
Help? Thank you very much,

March 21, 2011 at 11:22 AM

Ethan Dunham

@Monique - No there is no cross-browser way to do that yet.

@watts & @Lev - Your sites seem to be working fine for me.

March 21, 2011 at 02:57 PM


Nice! But in Opera 11.01 I see here only usual Arial font...

March 22, 2011 at 10:41 AM

Ethan Dunham

@Alex- please provide a URL when making statements like that. Opera 11.10 is working fine for me.

March 22, 2011 at 10:47 AM


where can I embed these font face on my HTML

March 23, 2011 at 11:13 PM

Ryan Bojanovic

Hi All!

I'm having problems with this.. I'm working on a client site and it seems to only work on Safari 5.0.3.

The url: syntaxstudios.net/dhgwa

If someone could look at this and let me know anything I'm missing out on, I would really appreciate it!


March 28, 2011 at 02:10 AM

Russell Bishop

Crazy simple, love the thought behind it. Good job chaps!

March 28, 2011 at 10:19 AM


Only works when IE9 is in compatability mode or on my local machine. No love on any remote server.

April 3, 2011 at 02:10 AM


Unfortunately I can't make it work on my WinXP IE7-IE8 test machines. The former fontsquirrel syntax (with smiley) is working fine on those machines.
Here is my test page (serving the demo file from fontsquirrel): http://4o4.ch/fontfacetest

For the first rule (DejaVuSansBook) I applied the old smiley-syntax, so the first paragraph is working for me in IE7-IE8. All the others show Arial instead of DejaVu.

April 7, 2011 at 02:27 PM

Ethan Dunham

@ms-studio - Seems to work fine on my IE8/7 XP machine...

April 11, 2011 at 04:47 PM


In Opera 11 some letters disappear...
In all other browsers it works fine (ie9, firefox 4, chrome 10)

April 13, 2011 at 09:07 AM

Yuri "AzX" Chetverikov

same shit as Oxana has.
several letter are just invisible at the end of the word :(

April 14, 2011 at 06:48 PM

Ethan Dunham

@oxana, @Yuri - Can you provide either a URL or screenshot of the problem?

April 16, 2011 at 11:07 AM


Damn. Still doesn't work in Firefox for me. I appended the htaccess snippets, did all that needed to be done, but it just won't show up for me. Ah! Anyone have any other ideas what I can do?

April 16, 2011 at 11:18 AM


re: @oxana and @Yuri:

I was experiencing the loss of final letters in Opera 11.01 in Win XP SP3. After upgrading to Opera 11.10, the problem went away

April 17, 2011 at 05:28 PM


I've used the Fontspring syntax for a while now (in conjunction with base64 encoded fonts via Font Squirrel), and I've hit a small snag with FF 4.0.


I'm using Century ModernFS Light for the top of the page <h2>s and on every other browser I've tried (Safari, Chrome, IE7/8, iOS, Opera) it works as intended, however, with FF 4.0 the heading renders properly, blinks, and renders properly again.

Am I going batsh*t insane?

Cheers :)

April 25, 2011 at 06:42 PM


Sweet, Made my Android very happy!

April 29, 2011 at 01:36 PM


I am pulling my hair out. Stupid IE8 keeps making fonts flash in and out randomly. Has anyone else experience this?

See example here: http://cleverrocket.com/about-us/

May 1, 2011 at 10:54 PM


Yea, I'm really struggling trying to get my fonts to work in any browser!


I'm trying to use Cyclone. I'm editing in Dreamweaver, and sometimes I'll go back to my index.css file and notice that:

font-family: 'CycloneInline', Arial, sans-serif;

has changed to:

font-family: CycloneInline, Arial, sans-serif; (without the apostrophes)

Help please!

May 2, 2011 at 03:04 PM


Thanks for the research. Im going to try this tonight.

May 3, 2011 at 11:48 PM

Submit a Comment

Comments are closed.