Web fonts have opened a whole new realm of possibility in web design. As an old timer web developer I can remember how excited I was by the possibility of loading almost any font into a website and using it for text. The web is much better for it.
So as web designers and developers go to create signatures for their clients, the natural question for them is "Can I use web fonts in an email signature?"
Unfortunately the short and simple answer is "no", you should not try to use web fonts or Google fonts in an email signature. Instead you should stick to the web safe fonts in the table below.
Why can't I use newer web fonts or Google Fonts in email signatures?
While the web has made amazing strides in terms of font support using the @font-face technology that is standard in all of the major browsers these days, unfortunately, email client support has lagged pretty far behind that. Some email clients do support web fonts including:
- Outlook Mobile App
- Outlook for Mac
- Apple Mail
- iOS Mail
- Google Android
- Samsung Mail (Above 8.0)
While support for the web font technology is growing in email clients that has enabled designers to start to make use of the technology on some marketing emails, there is a different problem altogether when adding fonts to an email signature. Attaching an email signature at the end of an email is not the same as sending out a designed HTML email from a service like Mailchimp, Campaign Monitor, or another bulk marketing email provider. The problem is that in an email signature we have very little control over the HTML that actually gets sent out.
The Problem Is the Style Tag
Web fonts in an email require the use of a <style> tag with a number of @font-face declarations inside of it. These font-face declarations usually call an external style sheet from a remote server. Using this method is generally possible using a bulk email service like Mailchimp and Campaign Monitor. But attaching an email signature is far different and much less "controlled" than an environment like MailChimp. Including a style tag in an email signature is not recommended because it will almost certainly get stripped out during the process of adding that signature into an email client especially those declarations that reference a remotely hosted files.
Let me explain this further. Let's say you have a perfect bit of HTML that a user copies into their clipboard including the style tag with the font face declarations. When that user visits their settings in their email client like Outlook, Apple Mail, or Gmail and paste that HTML into the signature editor there, the email client does not take those HTML instructions as is and save them as you wrote them. Instead each email client runs that HTML through its own process to determine what is acceptable and what is not. It can, and will, remove elements, attributes, and whatever it deems necessary from your beautiful HTML code. Sometimes it does this for security reasons, and other times it does it for compatibility reasons to make the HTML work better in that particular email client's HTML rendering engine.
Are there situations where it might work?
If your users are not pasting the email signature themselves into their email client, and instead you are applying the signature through a process that maybe IT has set up, then it could be possible that it could work. The important thing here is that the HTML is applied to the email without any conversion or anything being removed. You would need to test it within your environment and see how it works in your situation.
If you opt to try this out, remember two important things:
- Even still this would only work in the email clients mentioned above that support @font-face fonts.
- This would mean that every email sent from your company would require a number of additional files to be loaded. Across a large company this could have unforeseen ramifications on additional load.
So what do I do instead?
Since you can't rely on loading external web fonts, you need to work with only web safe fonts.
Web safe fonts is a term from the younger days of the Internet. The idea was that you can choose whatever font you want, but that doesn't mean that everyone will have that font on their computer, so you should really pick from a list of fonts that most people have loaded on their computer already. Generally this means sticking to a font that comes with an operating system, or possibly might come with a broadly adopted piece of software like Microsoft Word.
Even when you choose one of these web safe fonts you are not guaranteeing that it will work across the board, you are choosing to go with a majority, knowing that larger percentage of people will see the text as you designed it to appear.
Do I have to use web safe fonts for email signatures?
Yes unfortunately that is the case because of the limitations I mentioned above. Here is a list of web safe fonts to help you out:
|Times New Roman||99%||97%|
|Lucida Sans Typewriter||74%||99%|
Statistics are from CSS Font Stack.
Because no font is installed on every computer out there, usually when you add a style with a font declaration you add a font "stack". Meaning you identify a chain of fonts as the instruction. As the computer reads the signature HTML it checks to see if it has a particular font, and if not it moves on to the next one until it finds a match. Font stacks usually end with the most generic font possible like "sans-serif", which allows the email client to choose their default sans serif font. You can see an example of a "Helvetica" font stack below:
font-family: "HelveticaNeue-Light", "Helvetica Neue Light", "Helvetica Neue", Helvetica, Arial, "Lucida Grande", sans-serif;
But which font should I choose?
If you are looking for recommendations I've written a whole article about which of the fonts I'd recommend in an email signature. You can read all about the best fonts for email signatures.
This sounds complicated, what should I do?
HTML email signatures can be deceivingly complicated. I would recommend using an email signature generator like signature.email to create your email signature. It is far easier than researching which email client does what with your HTML and how to program it for the best compatibility across the spectrum of available technologies on the market. We've already done that for you and can save you a lot of time! Check out the tool and give us feedback on how it can be better for you!