Our RSS Feeds

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:

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

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.

Want to improve your email marketing?

Join over 20,000 other marketers & designers who get tips on improving their email marketing delivered directly to their inbox.

79 Comments

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?

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.

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.

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.

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.

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?

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.

“[…] 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?

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.

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 :(

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.

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!

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, 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 :)

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.

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?

@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.

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:

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.

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?

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 :)

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).

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 :)

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?

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.

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 :)

Taylor
20th May

Just a note, another email marketing company Stamplia copied this blog post nearly word for word to their blog page (see from the title “Web Font Email Experimentation” down).

did anyone find this - causing spam filtering issues? with a <link or @import?

Chris Bowler
7th June

Hi Lemuel,

This should not give you any issues with spam filters. You may have problems if you’re using a non-secure URL (http rather than https), so if you’re hosting your own font files, that could be the issue :)

Anthony
25th June

Hi there, this is a great article. A follow-up would be great as I’d love to know which major web font providers provides support for @import or linking.

I’m having trouble with importing fonts and the fall back font in outlook.

Outlook will register the font fall back I am using, but when I click download images it ignores the font fall back and uses Times New Roman (ew!)

If however I use web safe fonts it doesn’t do this. This happens in complex emails and a test one I made using text only.

Has anyone come across this before?

Thanks!!!

Chris Bowler
9th July

Hi Andrew,

There are definitely issues with Outlook and fallbacks for sans-serifs can be tricky. We’ve used “HelveticaNeue, sans-serif;” to ensure Times was not used. You should be able to use that as a fallback stack for web fonts that you’re importing.

Hi there none, that’s a great idea - for the time being, I don;t think there’s any harm in using all 3 methods and seeing how you go. Great reminder that we should run some more tests on this in the future!

I was looking at my mail the other day (Outlook Online), and found this email from Bluehost:http://i59.tinypic.com/28thr0y.jpg
As you can see, they have used the Montserrat, a Google Font that is also available on lots of other font libraries. I later opened this mail in Apple Mail, forwarded it to Gmail—they all worked.
I assumed that they didn’t use any code and simply put “Montserrat” in the code of the email, and because I do have it installed in my computer, I was able to see it. That wasn’t the case, because I opened it on my iPhone using the native Apple Mail client and it worked there, too.
Any explanations?

HI Zhirou, that’s very interesting! Montserrat isn’t a default iOS font, so either the font was imported, or a fallback was used. Perhaps you could post the email code in our forums? It would be well worth a look. Thanks, Zhirou - I hope we solve this one!

Just wondering what are the legalities surrounding using web fonts within email, I understand with commercial fonts you need to be licensed for their specific use, i.e. Web, App, Desktop so which one if any relate to email?

Hi there Mark, I haven’t seen that many examples of email-specific licenses from commercial vendors, so your best bet is to ask, prior to purchase. This is why the open-source licenses that Google Fonts are under are very convenient, as they don’t place restrictions on usage like many vendors and foundries do.