Using web fonts in email

Updated! For the latest results and techniques, take a look at our Web Fonts guide.

If you've ever flirted with using web fonts in your email designs, it may be your lucky day. With the @import CSS at-rule, support for less-traditional typefaces is looking better than ever.

For those who are keen to style up their text, but aren't too fussy about using fallbacks in some clients, web fonts in email are a real win. For starters, using web fonts is by far preferable to say, using images for headings and other styled text, given that they'll display regardless of whether images are turned off in the inbox. They'll often look crisper than images, too. Secondly, if you would otherwise use images for textual content, web fonts can potentially reduce load times, as only one request for the hosted font file is required, regardless of how many instances you use the font in a design.

Adding Google's web fonts to a design

While there are quite a few providers of web fonts out there (like FontShop), we decided to use Google Web Fonts, given that their library is free to use and as a result, ideal for experimenting with. However, you can choose any vendor you like, as long as they support font embedding using @import or <link>.

Admittedly, the hardest part of the process is finding the right font for your design in Google's near-limitless library. But lets say you've chosen one called 'Merienda'. Once you've tracked it down, click 'Quick-use', then on the following page, scroll down to '3. Add this code to your website' and click on the '@import' tab. The following code should appear:

@import url(http://fonts.googleapis.com/css?family=Merienda);

Copy and paste this snippet to the CSS styles in the head of your HTML code, like so:

<style>
    @import url(http://fonts.googleapis.com/css?family=Merienda);
   /* All your usual CSS here */
</style>

Now, you can use 'Merienda' as if it were one of the usual fonts available to us when designing HTML email:

h4 {
   font-family: Merienda, 'Times New Roman', serif;
   color: #444444;
   font-size: 24px;
}

And that's that. To double-check that all has gone to plan, preview your email design; here are the results in Apple Mail:

Web font in an email newsletter

Alternately, you may see the fallback in some email clients, so lets move on to which clients support @import (and web fonts in general) and which don't.

Support for web fonts in email using @import

Display of web fonts in email clients is far from universal. However, given that many major clients do support them (including Lotus Notes 8, surprisingly!) and the rest gracefully use any provided fallbacks instead, it's fairly safe to use. So without any further introduction, here's what web font support across the most popular email clients looks like today:

Email client Supports web fonts?
iOS Mail Yes
Outlook Info
Outlook.com No
Apple Mail Yes
Yahoo! Mail No
Gmail No
Android (default client) Yes
Windows Live Mail No
Thunderbird Yes
AOL Mail No

At this point, you may be wondering why we've favored using @import over say, the traditional <link> method for importing fonts. Well, we tested both and found that support for @import was just slightly better - @import worked in the Android default client, while <link> did not. Comparatively, earlier tests of the comparable @font-face method were far less promising and we don't expect much has improved since.

So, should we be using web fonts in email? If you would like to style up your text without relying on images and are not too fussy about a fallback displaying, then there's no harm in using this technique. However, given the rather patchy support for @import, we'd suggest steering clear of their use when designing for brand-conscious clients, or when it's essential to maintain a consistent look under most conditions.

Posted by Ros Hodgekiss

59 Comments

  • Ricky Synnot
    11th December

    Well, thats not a lot of coverage guys - do you think that the inclusion of these typefaces for some users (mainly mac users) would enhance the product overall? Or degrade the product (email newsletter) overall becuase there are different experiences going on?

    Typically in the past as web developers we’ve chosen ‘web safe fonts that work’ to ensure a consistent experience, but is this a good thing?

    In your opinion, is it a good end result to have the same base newsletter, and trick it up for devices that can run the special code?  Is that better?

    Love to hear your thoughts!

  • Jonathan
    11th December

    Utilizing a tool like http://litmus.com/email-analytics You can segment your list based on what email client your customers use. Send a custom font version to those that can support it and then either an image based, or “web safe fonts” version to those that can’t. This tailored experience can drive engagement.

  • Marco Aboytes
    11th December

    I like the Idea a lot, I like the idea to give your content as much attractiveness as possible and keeping text, instead of images.

    And still, I can use several font families in my styles, enhancing the mails with supported clients, and also make mails viewable by unsupported clients. Just the way I insert background colors for mail clients that block images.

  • Mark
    12th December

    But basically using webfonts is going to be seen by less than 10% of my recipients. That doesnt seem particularly useful. Without Yahoo, Gmail, Microsoft, or Outlook, we are basically talking about people using phones to read their email.

  • Ros Hodgekiss
    12th December

    Hey all, thanks for the great feedback so far! Happy to provide my opinion on a few things here :)

    @Ricky - The notable thing about this technique is that while folks who have email clients that support web fonts will likely benefit from a ‘tidied up’ appearance, whereas those who don’t will really be none the wiser. Even if only 30% of subscribers benefit, is that better than no benefit at all?

    From personal experience, I dare say that much of the desire for a ‘consistent’ experience is client-driven. I’d argue that we shouldn’t always design for the lowest common denominator, but simply ensure that whatever fancy things we add degrade gracefully. This is all perfect-world stuff and perhaps a good topic for a blog post!

    So yes, I’m all for tricking up newsletters, as long as it doesn’t impact usability and the overall message. Plus it has to degrade well, even in worst-case scenarios (eg. images off, Lotus Notes) :)

    @Jonathan - That’s a great tip, thanks for sharing that link!

    @Marco - I think the comparison with background image support is very apt. I’m looking forward to seeing your future newsletters :)

    @Mark - Of course, the number of folks a technique like this will benefit will vary from sender to sender. However, in our last email client popularity report, we found that the email clients that supported web fonts accounted for almost 50% of all recorded opens - for others, it may even be more. With a different list, you may find that you’ll have enough mobile/iOS recipients to make a simple technique like this one an attractive option.

    Thanks, everyone! Really enjoying the conversation here, so feel free to chime in :)

  • Remy Bergsma
    12th December

    So glad you left out Comic Sans MS Ros ;)

    But in all seriousness: nice post, very good overview of web fonts use in emails and their support (or non-support) in email clients.

    I’m all for having text be in true fonts instead of in images - not just because it will be visible even when images aren’t loaded (yet), but also because you can make links out of separate lines of text more easily than within an image - even when you’re using image maps.

  • Justin
    14th December

    You mention Typekit, but their only two options for loading fonts are both SCRIPT tags (no @import support, apparently).

    A somewhat thorough search for Typekit in email design brought up nothing… So do you have a secret trick up your sleeve or was that an oversight?

    Guess I’m off to Google Web Fonts for now!

  • Matt
    15th December

    I suppose you could use @import to grab a file from your own server improve open rate tracking.

  • abimael martell
    15th December

    use images….

  • Ros Hodgekiss
    15th December

    Remy - thanks for the great reminder and as always, for your support. :)

    Justin - You’re right, they only support Javascript embedding for now - that’s a real shame. Definitely an oversight on my part then, so I’ve updated the post. Off to Google Fonts it is!

    Mat - That’s not a bad idea, as I know Facebook do the same with sound files for the same reason. For Android in particular, there could be some real benefit, so I’ll pass that on to the team. :)

    abimael - No…. ;)

  • Stephen
    15th December

    See what you’re saying about 30% being better than none Ros but when you have clients who demand that their ‘brand font’ be used - they won’t stand for it to fall back to the nearest websafe version.

    They best way to do it is still images in my eyes (in conjunction with typed text of course).

    Although the thread seems to suggest support is good the results seem to differ slightly. No support for Gmail, Yahoo Mail, Windows Live Mail or Outlook.com, not to mention the likes of Outlook 2007 / 2010… you’ve got to ask, is it worth it?

  • Farzad Qasim
    15th December

    Considering the large amount of outlook users to date, i dont think this is of much practical use. Without media queries its actually quite useless.

  • Scott
    16th December

    Great information about using @font-face over <link> structure. I’ll be using this with http://autoletter.io when it’s launched.

  • Rakesh Patwari
    16th December

    Great post with real good points over the conversation too.. I would say conversations add lot of value to the overall post.
    here are my thoughts, if you know your target very well (email clients they use, demographics..all that great stuff) then this is a sure winner, else you need to trade off between consistency and flexible look and take a call. I would say use the web fonts only to the design elements which can vary but not branding elements that cannot be compromised - you have images for that.

  • streetpc
    16th December

    “[…] they’ll display regardless of whether images are turned off in the inbox.”

    A precision: The text will be displayed, but not necessarily with the right font, which makes it unsuitable for, say, using icon fonts. Would be worse than using an image because you cannot replace with alternative text like you do with images.

    Also, I don’t get why some clients (apparently Android and Thunderbird) authorize @import by default while blocking images, that’s basically the same privacy issue, isn’t it?

  • Joseph
    19th December

    So this is good for mobile and Mac users and that’s pretty much it. Most email clients completely ignore the <head> content which is why we use inline styling only.

    Safe to forget about this article.

  • Jay
    19th December

    What does the “i” for Outlook in the table mean?

  • Buzz
    19th December

    @Jay - The “i” indicates that web fonts are only supported in Outlook 2000. Neither a definite yes or no.

  • Irshad Ahamed
    19th December

    What is the use or purpose of this if it is not working in Gmail/Yahoo/Outlook.com/Aol..etc? This is useless, better to use image to create fancy text in emails.

  • David Greiner
    19th December

    A quick note to those not sure how useful this technique will be, it’s all about your audience. With Campaign Monitor for example, more than 60% of our subscribers use Apple Mail, iOS or Android, so for us the effort would likely make sense.

  • Manu
    19th December

    Very interesting information, but as long as those figures become way more significant (I’m talking about 90% rather than 50%) it’s not something I’m going to be able to sell to my clients.

  • Rolf Inge Holden
    20th December

    Can’t wait to try this! As per your usual awesomeness can I expect to see this implemented easily into your editor at some point? :-)

    Keep up the amazing work!

  • Avangelist
    21st December

    What’s the point?
    You’re making another http request which is going to be costly to time of loading the mail.

    It isn’t the fact that there are so few mail clients that will accept it, even fewer accept you sticking a style sheet in and not using inline styles full stop.

  • Jelmer Borst
    21st December

    So Android does support it, but GMail doesn’t? What the heck… nevertheless I think the overal support is quite crap; welcome to HTML e-mail.

  • Marcus Taylor
    4th January

    Have you got examples of usages of this technique out in the wild?

  • Rick Hocutt
    4th January

    I believe that support for background images is also fairly poor so If you opt to use text vs. an image it would have to be against a plain colored background. If you have imagery, textures etc in your background you will still have to resort to using images. I’m with most of the others in that support is low and it’s pretty rare that our HTML email backgrounds are plain solid colors so it seems it may still be a while until we can code email the way we do web pages :(

  • Ros Hodgekiss
    7th January

    Hey there Marcus, our most recent newsletter used this technique and we’ve already seen customer campaigns that have used web fonts. I’d be keen to showcase one in our gallery at a later date, so stay tuned and hopefully we’ll have a great example for you shortly.

  • Wordpress Developer
    7th January

    I will give this a try. There is a fall back any way.

    The time will come when most of browsers and email client will start supporting it. Not sure about the Outlook though.

  • Finge
    14th January

    Can’t wait to try this out. Is there any way to do this using the templates from the template editor? Or would I first have to design the template, then download to add the code, then upload?

  • Ros Hodgekiss
    16th January

    Hi Finge, you’ll have to manually edit the template to add the @import url(...). However, if you want to define the font by using <span > or similar, you can do so in the editor, either by adding code directly to <singleline> areas, or to the ‘source’ view of <multiline> areas. Hope this helps!

  • New Leaf Interactive
    7th February

    Just a note to everyone who is looking at their total percentage of open rates per client and poo-pooing the technique…  Be sure not to confuse the importance of *opens* with the importance of *clickthroughs*. 

    Let’s say you email 100 people, and 60 of them open on a non-webfont client, and 10 click through to your site.

    But then the remaining 40 people open on a webfont friendly client, and 30 click through to your site. 

    Suddenly that smaller audience becomes more important than the larger one. 

    And with mobile opens at around 20-30% and climbing, it’s going to be increasingly silly to ignore giving the mobile audience a customized experience.  Just sayin.

  • Bart
    22nd February

    How would this work out with Webtype.org fonts, which are bound to a certain domain name?

  • Ros Hodgekiss
    22nd February

    Bart, unfortunately the technique used by Webtype.com likely won’t work, as we can’t guarantee which domain will be used to request the font. For now, Google Fonts is the only service which we know works off the bat, but keen to hear if other services make it possible to embed fonts sans JS :)

  • Bart
    23rd February

    @Ros, does it make a difference when I have set up a custom domain for sending emails through CM?

  • Ros Hodgekiss
    23rd February

    That’s a good question Bart. The only way to know for sure would be to experiment with Webtype.com, as we really can’t guarantee that their per-domain setup will play nicely with us. Alternately, it may be worth getting in touch with their team, in case this is something they have experience with.

  • Martin
    28th February

    The fallback doesn’t seem to work in outlook 2007, just defaults to times new roman. If I remove the web font, then the fallback works.

    Any ideas?

  • Jemiina
    4th March

    I’m using Open Sans through Google with @import and I’m having the same problem with Outlook 2007 & 2010 defaulting to Times New Roman on editable multiline sections. Surrounding singleline elements with old school font tags helped to get the fallback (arial, sans-serif) working for those, but even with font tags being inside the multiline sections does not give a consistent fallback to Arial on Outlook. Could it be because of the apostrophes surrounding ‘Open Sans’ in the font declarations that messes up Outlook, even with the overkill of declaring fonts in the head style, inline style & font tags?

  • Ros Hodgekiss
    5th March

    @Martin and @Jemiina - This is really interesting, a similar font issue was being discussed on our forums. I recommend you swing by and see what’s been said so far. Naturally, we’d like to get to the bottom of why this is happening for some people and not others.

  • Keith
    24th March

    Hi, I’ve used similar code as above but can’t get it to work in any email client. Please email me for private link, thanks

  • Robert Ralph
    3rd April

    Just as an FYI, Gmail actually does support Web fonts in a very very restrictive capacity.  If you are able to include your fonts from the same sending server as your email then they will actually display.

    For example, if you were able to host these files on the same web server that the emails originate from… say ‘myhost.com’ and in the include statement the .woff file is also on myhost.com the font will indeed show up.

    Me and a fellow programmer have successfully shown that it’s an issue where Gmail’s new <div> stylings will remove any includes that dont originate from the same server as a security feature.

    My fellow programmer also demonstrated that it’s best to not just rely on .woff, but also vector type includes.  These are above my knowledge, but in short you’d have an include statement that looks like:

    @font-face{font-family:Futura-Bold;src:url(‘Futura/futura-bold-webfont.eot’);src:url(‘Futura/futura-bold-webfont.eot?#iefix’) format(‘embedded-opentype’),url(‘Futura/futura-bold-webfont.woff’) format(‘woff’),url(‘Futura/futura-bold-webfont.ttf’) format(‘truetype’),url(‘Futura/futura-bold-webfont.svg#futurabold’) format(‘svg’);font-weight:normal;font-style:normal;}

    Admittedly this is hefty, but gets the most coverage.  Seemingly only two places will consistently break down - Lotus notes (the devil), and Gmail on Firefox web browser.

    It’s unclear if multiple calls of this manner fault previous calls as our testing would occasionally fruit inconsistent results.

  • Robert Ralph
    3rd April

    Well that was unintended.  I put a ‘div’ statement as an example it broke out of the container.  May want to resolve that :-/

  • Ros Hodgekiss
    3rd April

    Keith - Your best bet is to get in touch with our team, we’ll happily take a look for you.

    Robert - Now, that is very interesting! So effectively, we’d have to host the images to get this to work. Hm, one to think about.

    Sorry about the code breakage in the blog, we’re looking into what we can do about that. Very glad you brought it to our attention, though!

  • Elliot
    2nd May

    Hey guys

    just a quick note on the Outlook 2000 ‘support’ - this is technically possible but unlikely. Outlook 2000 uses whichever version of IE you have at the point you install it, so if you did go and install Outlook 2000 now, having IE 10 on your machine, then yes, web fonts would be supported. However it’s more likely that many of the Outlook 2000 users (if there are still any out there) would be using IE 5 or 6.

  • Mike
    11th June

    Wait, so Google has their own list of fonts that Gmail won’t support?

  • Ros Hodgekiss
    11th June

    Elliot - thank you for these notes, that’s awesome to know :)

    Mike - As always with Gmail, there are technical caveats :) Watch this space, as we’d love to see if the recent Gmail update results in any changes on this front.

  • Eugene Krivoruchko
    14th June

    I am trying to do what Robert suggests by including my .eot and .woff into the archive with additional files to my template in Campaign Monitor so that they are stored on the same server from which email was sent.

    That doesn’t seem to work though, fonts on the template won’t load at all from local urls. Any ideas?

  • Mathew Porter
    21st June

    Im giving this a test on my campaign that im sending this week to see what upport it has as font-face has had support in browsers since ie6, so interesting to see what clients support is like.

  • PKHunter
    13th August

    Will this work with Outlook 2007? No one I know uses “Outlook 2000” anymore, not even archaic corporate organizations.

  • Ros Hodgekiss
    14th August

    Eugene - Sorry for the late response, at present, you can’t import your font files into Campaign Monitor, I’m sorry to say. For copyright reasons, it’s not likely that we’re going to introduce this, either. Your best bet at present is to host the fonts on your own server, then link to them from there. You may want to see how Panic implemented this recently.

    Mathew - We actually did some testing recently on this and will be publishing our results shortly. Stay tuned to this blog :) In the interim, let us know if there’s a particular client you’d like advice on.

    PKHunter - Web fonts won’t work in Outlook 2007, I’m sorry to say. This post was written in late 2012 and as mentioned to Mathew, we’ve updated our results since then. Stay tuned and we’ll be sure to give you a full wrap-up of email client support for web fonts shortly :)

  • BenM
    21st August

    A remark which does not directly concern fonts rendering: you said “they’ll display regardless of whether images are turned off in the inbox”. The web font or the default font ? Because if the webfont is displayed even if images are turned off, it would allow to track opening on Android, Thunderbird and Outlook 2000 by adding a dummy font (like the 1-pixel gif).

  • Ros Hodgekiss
    22nd August

    Hi BenM, that’s a clever idea. We’ve also had silent sound files recommended for better tracking, so those are two approaches we’ll keep in mind, should we update how we record opens. Thank you so much for the suggestion - we’ll be sure to keep you posted if this is something we look into :)

  • Karl
    22nd August

    No one has asked it, and I might be being stupid, but can I not added the custom CSS for changing the font in the Drag and Drop section of Mailchimp?!

  • Ros Hodgekiss
    22nd August

    Hi Karl, we’re not quite sure how it works in the Mailchimp editor, but from our knowledge, adding web fonts to email using @import (unlike system fonts, eg. Verdana, Arial) generally requires some manual work. Have you seen otherwise elsewhere?

  • Roshan Shrestha
    29th January

    Hi Robet Ralph,

    followed your instruction and included following in message but still no luck

    Any suggestions.

    <html>
        <head>
       
     
        <title>Birthday Reminders for August</title>
        </head>
        <body><style>
        @font-face{
        font-family:“CatCatCatD”;
        src:url(”./Fonts/618eefb2-5ccd-4536-9580-c1857eb655e5.eot?#iefix”);
        src:url(”./Fonts/618eefb2-5ccd-4536-9580-c1857eb655e5.eot?#iefix”) format(“eot”),url(”./Fonts/bd900c61-f525-4cc3-a01b-a05deba32714.woff”) format(“woff”),url(”./Fonts/3007df0b-f523-4c7f-ac67-672aca81c026.ttf”) format(“truetype”),url(”./Fonts/dd11cb21-d1bb-4814-a04e-df6e328fd582.svg#dd11cb21-d1bb-4814-a04e-df6e328fd582”) format(“svg”);
        }

        </style>
        Here are the birthdays upcoming in August!
        <table>
        <tr>
          <th>Person</th><th>Day</th><th>Month</th><th>Year</th>
        </tr>
        <tr>
          <td>Joe</td><td>3rd</td><td>August</td><td>1970</td>
        </tr>
        <tr>
          <td>Sally</td><td>17th</td><td>August</td><td>1973</td>
        </tr>
        </table>
        </body>
        </html>’;

  • Roshan Shrestha
    29th January

    Opps my html renderred.

    Actually tried with adding style in the body as well as head of the html message

    <//style>
        @font-face{
        font-family:“CatCatCatD”;
        src:url(”./Fonts/618eefb2-5ccd-4536-9580-c1857eb655e5.eot?#iefix”);
        src:url(”./Fonts/618eefb2-5ccd-4536-9580-c1857eb655e5.eot?#iefix”) format(“eot”),url(”./Fonts/bd900c61-f525-4cc3-a01b-a05deba32714.woff”) format(“woff”),url(”./Fonts/3007df0b-f523-4c7f-ac67-672aca81c026.ttf”) format(“truetype”),url(”./Fonts/dd11cb21-d1bb-4814-a04e-df6e328fd582.svg#dd11cb21-d1bb-4814-a04e-df6e328fd582”) format(“svg”);
        }

        <///style>
        <// p >Here are the birthdays upcoming in August!</p/>

  • Ros Hodgekiss
    31st January

    Hi there Roshan, could you kindly post code samples in our forums? We’re happy to take a look at what might be happening there. Thanks for your input! :D

  • e11world
    15th March

    It’s very annoying that WEB MAIL clients such as Yahoo, outlook.com and Gmail which run on browsers that support many new font embedding methods such as Google Fonts and Typekit don’t provide support for it. It’s actually stupid. They run on the browser, why are there limitation of what font it uses if browsers can support it all?

    I can understand Outlook but outlook.com? A fairly new update to hotmail should have it working and Gmail which is by Google should also have it working. Helloooooo, you have Google fonts. Come on Google. Get with it. Supporting Android but not Gmail is stupid.

  • Paola Gutierrez
    30th March

    Hey! is it possible to set a different font-size for different families? So when the client doesn’t support the @import CSS at-rule I can adjust the font fallback size?

  • Ros Hodgekiss
    1st April

    Hi Paola, at this stage, it’s only possible to adjust font-size (amongst other attributes) using JavaScript at this stage… Which isn’t supported in email :( Our Guide to Web Fonts has a great section on choosing fallbacks based on their x-height, so that may be useful to you :)

Got something to add?

Sign up for free.
Then send campaigns for as little as $9/month

Create an account