Can I Add Google Fonts to My Email Design Toolbox Yet?


July 7, 2015 Update:
Interested in using Google fonts? Check out our article on Making Custom Font Stacks Work in Outlook.

You betcha! Last I checked, this is the 21st century!

We know what you want: flavorful fonts with an easy fallback to make your emails POP! Google Fonts makes integrating new typography a total cake-walk!

Do you need something creepy for Halloween? Maybe a font to make your readers feel like they’re in the Wild West?

Let’s get started with this super simple example from the Google Fonts getting started page.

    <link rel="stylesheet" type="text/css" href="">
      body {
        font-family: 'Tangerine', serif;
        font-size: 48px;
    <div>Making Email Beautiful!</div>


Which should come out looking like:

Making Email Beautiful!

Not seeing anything special? Perhaps you’re not viewing it in a supported browser.

Support for Google Fonts

Some clients are still in the Dark Ages and don’t support Google Fonts, but the following ones do:

Client Supports Google Fonts
Apple Mail 4, 5, 6
LotusNotes 8
Outlook Express
Thunderbird 13
Android 2.3, 4 (Native Client)
iPad (Native Client)
iPhone (Native Client)
Kindle Fire (Native Client)

You’ll notice that these fonts have wide support in mobile clients. Since mobile is on the warpath to conquer all email opens, we think the time for web fonts has come.

How it Works

Google hosts these fonts, so you really don’t have to do much. You just need to set up a link to the stylesheet, like this:

<link rel="stylesheet" type="text/css" href=""> 


Then create a font stack, just like you normally would.

p {font-family:"Tangerine","Times New Roman",Georgia,Serif;}


In our sample above, we called the Google Font first. If the client can’t use it, the next font in the stack will be the fallback. It’s very important to find a suitable and well-supported fallback font. Not everybody will see the new font, but unless minor changes in line height are an issue, it shouldn’t make too much of a difference. Check out the full list of Google Fonts here.

Yeah, we know: when it comes to HTML email, typography is still stuck in the 20th century. However, with mobile clients (and their stellar support for Google Fonts) on the rise, we can finally have our cake and eat it too.

Author: Email on Acid

The Email on Acid blog is on a mission to share email best practices, industry news, and solutions to most annoying email client bugs. Plus, we like to have a little fun along the way. Learn how to join the party and contribute to our blog.

Author: Email on Acid

The Email on Acid blog is on a mission to share email best practices, industry news, and solutions to most annoying email client bugs. Plus, we like to have a little fun along the way. Learn how to join the party and contribute to our blog.

12 thoughts on “Can I Add Google Fonts to My Email Design Toolbox Yet?”

  1. We’ve tried Google Fonts multiple times in our mailings, but we keep encountering a problem: The mail won’t show the Google font or the fallback fonts when opened in Outlook 2007. Instead, we always get Times New Roman.

    If anyone has found a workaround for this, I’d love to hear it.

  2. *Can* we add Google Fonts? Sure!

    *Should* we add Google Fonts? Unless you’re sure that your target audience is comprised overwhelmingly of Apple device toters, it’s still a big fat sad “Nope”.

    A quick test reveals that more platforms DON’T support Google Fonts than do. Namely:

    : Lotus Notes 8.5
    : Outlook 2002, XP, 2003, 2007, 2010, 2013
    : GMail on Android and iPhone
    : on Android and iPhone
    : Windows Phone 7.5
    : All [repeat: ALL] webmail platforms

    Convincing one’s clients – particularly those with a rightfully protective sense of their company’s/brand’s identity – that an email design will look different on a few email platforms due to non-webfont idiosyncracies is already difficult enough. Getting them to accept that they’re going to see differences across a significant majority of platforms is going to be near impossible.

    Frans: There’s an issue with fonts that have multiple-word names with spaces, e.g. ‘Helvetica Neue’, and Outlook that can cause this stubborn TNR appearance. We discovered that removing the quote marks around the font names solved this [despite it being contrary to W3C recommendation… but hey, this is email; standards should be left at the door anyway]. Having said that, the webfont test I just ran used the single-word Tangerine font, and the issue still occurred, so I’m not sure there is a solution to the 2007/TNR problem 🙁

  3. Hey Frans,

    If you use !important on any inline style rule Outlook 07-13 will skip it. So you can use something like this to get Arial in Outlook and a Google font when supported:

    Some text
  4. I am puzzled by your article, as I’ve avoided using linked stylesheets in emails, for the last 10 years, as they basically didn’t work in many email clients.


    Here’s what MailChimp say on the subject:

    Use inline CSS.
    Referencing CSS files on your server like this is not very reliable:
    <link href=”” rel=”stylesheet” type=”text/css”>


    But things change and I’d like more fonts. So please could you clarify your advice, including whether it’s OK for WebMail Clients and when email content is copied-and-pasted for social clients.

  5. Pete,
    The only clients that support web fonts are the ones listed in the article, I know it’s a very short list. I’m not sure what you mean by “social clients,” but copy/paste is a very unreliable way to send an email. Hope that helps!

  6. Thanks! When I said, “copied-and-pasted for social clients”, I had in mind when people receive an email and copy-and-paste content from it into e.g. facebook. I’ve seen this happen several times and even the copied content going viral on rare occasions, so it’s useful if email content is at least somewhat likely to look good when pasted.

  7. Hi All:

    Just for check an other way to develop code:
    Did you try to put css style into body section?
    Since most of the client overwrite head section by it’s own framework, it could be possible to work fine.
    Maeby the line <link rel=”stylesheet” type=”text/css” may not work out of the header.

    Any way, it’s just a suggestion.


    A bit off topic. Please pardon.

    This is about a method that potentially impacts a billion people. Join us if you like the idea.
    We are testing orthographic smart-fonts served out of The CSS looks like follows:
    (Notice the ‘text-rendering’ and ‘font-feature-settings’ selectors)
    @font-face{font-family:singfont;src:url( format(“woff”)}
    .sing{font-family:singfont;text-rendering:geometricPrecision;font-feature-settings: “liga” 1;}
    These fonts are an alternative to double-byte Indic, very difficult to learn and type. We call the method dual-script. The underlying code is from SBCS (Latin-1) native grammar compliant romanized Indic. And the fonts show the complex forms of the native scripts via the ligature feature in OpenFont. The text looks much similar to Icelandic in the absence of the smartfont. Although our test Singhala font above has 2500 ligatures (as opposed to 5 in some English fonts) all recent versions of browsers as well as smart phones show the text of the rough shod design of our font.

    The frustrating part is that web based clients such as gmail / yahoo mail do not accept the @font CSS selector. The reason probably is because these pages still provide a hard coded list of fonts.

    They can have two additional things:
    1. Allow the email writer select fonts from the system risking the receiver not having them.
    2. Let font servers register their CSS pages with them so that uses can directly select the web fonts.



  9. Sooo.. is it *advisable* yet to use web fonts in emails? And is it better to do so via the <link> than the @import? Thx!

Comments are closed.