Last year I read Jan Constantin’s post “Typographic Design Patterns and Current Practices1” and straightaway wanted to do something similar with email. At the time I was studying responsive typography on the web, trying to break down the websites I liked in order to understand what made the typography work so well, then attempting to apply those findings to email design.

After seeing Constantin’s work, I also wanted to explore how other email designers were handling responsive typography. So, I amassed 50 emails across various industries that I think do a good job with typography to see if any patterns emerged. You can skip straight to the Google Doc showing the raw data and results2.

Given that around 50% of emails are opened on mobile3, all of the emails in the study needed to be responsive, have a single column of live body text, along with a heading. I collected statistics at three widths: full-width (desktop), mid-sized (450 pixels) and small (320 pixels).

With a sample group of 50, I’m not expecting statistical significance; I just wanted to identify some trends. By “average,” I am referring to the mean; the most popular is the value that occurs most often; and in some cases I note the median or middle value. All of the emails were deployed between November 2014 and January 2015, when I carried out this work. I used tools such as WhatFont6, Charcounter and WebPagetest7. I haven’t had time to triple-check it; feel free to email me8 anything wonky.

Most popular serif body typefaces: Georgia (24%), Merriweather and Times (4%)

Serifs were used 10% more for body copy than for headings.

Only 5 different serif typefaces were used in body copy, versus 15 different sans-serifs.

24 different heading typefaces were used (16 only once).

20 different body copy typefaces were used (11 only once).

Times New Roman was not popular; it wasn’t used even once as a heading typeface.

Helvetica was the most popular heading typeface overall, used by 16%, as seen in Offscreen12 and TGD13’s newsletters. Georgia was the favorite for body copy (24%), seen in Mr Porter14 and The New York Times15’ newsletters. The two typefaces Merriweather and Open Sans, from Google Fonts, are creeping in and can be seen iOS Dev Weekly16 and InVision17’s circulations.

Constantin noted a surge in the use of serifs for body copy on the web (61.5%), whereas this study placed it at 36% for email. He possibly included more news websites, which tend to skew serif. You also don’t see as much long-form writing in email because the bulk of the content usually resides on a landing page. However, one lovely example is Craig Mod20, who uses the serif Lora from Google Fonts for both headings and body copy. Most often sans-serifs and serifs are mixed, like this classic Helvetica-Georgia combination from MailChimp21.

Butterick’s Practical Typography states28, “Start every project by making the body text look good, then worry about the rest.” The recommendation to build out from the body copy was repeated in all of the typography articles I’ve read. What’s key here is maintaining the proportions between the font size, measure (line length) and leading (line height) across various viewport widths.

Reading distance is a key consideration when choosing font sizes. On the desktop, with an arm’s length between me and the monitor, Robocat’s 20-pixel body copy set in Helvetica (right) is a more comfortable read than Patagonia’s 14-pixel Muli (left). iA explains29 how, for its Writer app, it made the type sizes bigger on the iPad than on the iPhone because you hold the iPad a bit further away.

3020-pixel body font (right) is easier to read at this distance than the 14-pixel body copy (left). (View large version31)

Another variable to keep in mind for right proportions is the measure32, that is the width of a body of type, measured here in pixels or characters per line, because email developers typically don’t work in ems. Robert Bringhurst recommends 45 to 75 characters33 for a single-column desktop page, with 66 characters (counting both letters and spaces) being ideal.

600 pixels is the most popular width for desktop templates (623 pixels being the average, and 480 to 760 pixels being the range).

540 pixels is the average width of desktop columns.

78.5 is the average number of characters per line on the desktop.

53.86 is the average number of characters at 450 pixels.

39.02 is the average number of characters at 320 pixels.

The measure ranged from 22 to 57 characters on mobile.

76% fell into the 36 to 46 character range.

I did a quick test using Georgia set at 16 pixels at the average measure of 540 pixels, and it gives us a character count in the 70s. Not bad because 75 is the top of the range. Ideally, though, we want to be closer to 66 characters, giving us a measure of around 480 pixels.

Constantin found that websites average 83.9 characters per line, whereas this study found desktop emails average 78.5 characters. For mobile email, we drop down to 39 characters on average per line. Typecast recommends sticking between 35 and 40 characters37 on a typical smartphone; 48% of the emails in this study fell into that range.

Desktop emails have become narrower in recent years due to the uptake of scalable layouts, which helps us stay within the 45 to 75 character range. 600 pixels was the most popular width for desktop templates in this study, used by 53%; overall, widths ranged from 480 to 760 pixels. If you want a wider column, then just increase the font size until you hit the optimal number of characters, Trent Walton has a nice trick using two asterisks38 — the first marks the 45th character, and the second marks the 75th. So if at any point the two asterisks appear on the same line of text, he knows it’s time to increase the font size. Nifty!

1.51 was the average desktop ratio between line height and body copy (Constantin found 1.46).

The ratio between line height and body copy drops to 1.49 at 450 pixels.

The ratio between line height and body copy drops to 1.45 at 320 pixels.

22% tightened their line height on mobile.

52% set the line height in pixels.

24% set the line height in percentages.

The average line length divided by line height was 23.1 (Constantin arrived at 24.9).

1.38 was the average ratio of paragraph spacing to line height (Constantin had 1.39).

A classic rule of thumb is to make the line height 1.5 times the size of the body copy. So, a 16-pixel body font multiplied by 1.5 gives us a line height of 24 pixels. This study was spot on: The average ratio of line height to body size was 1.51. The wider the measure, the more generous you can be with the line height.

Tim Brown refers to this as molten leading39, or a fluid line height. Jason Santa Maria explains40, “As your eye gets to the end of a long line of text it needs that cushion to get to the next one without getting lost… If your lines are shorter you can pack them in a little tighter.” We did see a reduction in line height on mobile, dropping from 1.51 down to 1.45.

41The New York Times’ line height for its Cooking brand tightens from 30 pixels on desktop to 25 pixels on mobile (its ratio to body copy dropping form 1.6 to 1.5). (View large version42)

52% of email designers set the line height in pixels. Some, like Semplice43, changed their line height at different breakpoints. 24% used percentages. For instance, Lagom44 set its body copy to 150%. Oliver Reichenstein45 gives 140% as a “good benchmark” — a lot depends on the typeface. Paul Airy recommends using percentages46 for line height in email because pixels are more awkward to set proportionately. However, developers have typically stuck with pixels because they render consistently across email clients.

Oliver Reicheinstein states49, “With high contrast screens it’s preferable to choose either a dark grey for text or a light grey for the background, instead of a hard black on white”. While subtle variations in grayscale can add contrast and texture, body copy that is demoted too far can be hard to read.

Jason Santa Maria recommends giving typefaces with a heavier typographic color52 a greater line height or a lighter hue, so that they don’t overwhelm the rest of the content. Developers occasionally adjust text color across viewports due to the way fonts render at different sizes. It’s impossible to accurately judge type in Photoshop; you need to eyeball it in the browser using either self-made prototypes53, Typecast54 or Typetester55.

56Center-aligned body copy can be difficult to read because you have to find the start of each line. (View large version57)

When testing emails with users, the feedback was always that center-aligned body copy is harder to read. “Maybe some sections like that, where there’s quite a lot of text, it’s just a little difficult to read. I guess it’s because the text is center-aligned,” said one participant via UserTesting58. Shorter line lengths on mobile exaggerate the issue. Captions, the odd short sentence and headings were fine, but once you get into paragraphs, stick with left-aligned text. As mentioned in “An Ode to Centered Text59,” whole paragraphs should never be centered.

30 pixels is the most popular size for primary headings on desktop, used by 18% (also, 30 pixels was the median size, and 31.6 pixels was the average size).

There were two primary groupings for headings on desktop: 24 to 26 pixels and 28 to 36 pixels

2.0 was the average ratio of body copy to primary heading (31.6 and 15.7).

1.2 was the average ratio of primary headings to line height on desktop (ranging from 0.65 to 1.8).

62% of primary desktop headings were not linked, 38% were.

68% didn’t change their desktop heading size at 450 pixels. Of those that did, 87.5% went smaller.

64% made primary headings the same size on both mobile and desktop (one scale).

30 and 32 pixels were the most popular sizes for headings on mobile (both 12%).

28.48 pixels was the average size of primary headings on mobile (320 pixels) (and 26.5 pixels was the median heading size on mobile).

1.17 was the average ratio of primary headings to line height on mobile.

Only 14% used caps for primary heading (fashion retailers mostly).

72% used a secondary heading.

27.9 pixels was the average size of secondary headings on desktop.

Many email developers don’t employ h2 tags, h3 tags and so on; so, I decided to go with whatever was in use, making note of the largest and second-largest heading sizes, using WhatFont. 30 pixels was the most popular size for primary headings in desktop email, smaller than Constantin’s finding of 38 pixels on the web. It was perhaps chosen for convenience because it does a fair job across desktop and mobile.

64% used a single heading scale across all viewports; of the remaining 36%, 87.5% went smaller on mobile. For instance, Mr Porter60 dropped from 30 to 25 pixels on mobile, a subtle tweak that results in a more elegant feel compared to the clunky desktop headings.

There’s less consensus on heading sizes, although 2× (around 32 pixels) was the average ratio between the body copy and largest heading in use on the desktop. For comparison, Typecast mentions63 setting their h1s to 3×, although you’d expect larger headings on the web. You can use a tool like Modular Scale64 to experiment with different ratios, and there’s always the classic typographic scale:

As an alternative to using letter size to establish visual hierarchy, Marko Dugonjić suggests68 using a variety of style options to create tension, such as italic, all caps and small caps; see his live demo69 (select “Hierarchy with style”). This approach is particularly useful on mobile, where there’s less space for large headlines; you could also switch to a condensed font. Headings are one area where designers tend to take a more creative approach. They had greater variation in font sizes and alignment and an increased use of web fonts compared to body copy.

The pre-header resides at the very top of an email, the first piece of HTML text displayed, along with the “From” name and subject line on most smartphones. In this study, I’ve distinguished between instructional pre-header copy, such as “View online,” and snippet text that is more descriptive and that often complements the subject line. Litmus has a detailed review of pre-header text70, along with a support chart.

66% used pre-header text on the desktop.

36% had only instructions, 33% had instructions and a snippet, and 30% had only a snippet.

11 pixels was the most popular size on desktop, used by 33%, then 12 pixels (18%), then 10 pixels (12%) (with 12.3 pixels being the average size).

They ranged on desktop from 9 to 18 pixels.

The ratio of desktop pre-header text to body copy was 0.78.

The average ratio of pre-header text to line height on desktop was 1.11.

76% used a sans-serif typeface.

Arial was the most popular sans-serif, Georgia the most popular serif.

22 different pre-header colors were used, #000000 being the most popular, then #999999.

82% kept their pre-header text on mobile, while 18% hid it.

11 pixels was the most popular size of pre-header text on mobile, used by 40%, then 16 pixels (22%), then 14 pixels 18% (the average font size was 12.9 pixels).

They ranged from 8 to 16 pixels on mobile.

71% kept it the same size on mobile, 22% made it bigger, and 7% smaller.

1245 was the average Speed Index, as measured on WebPagetest. (Best practice goal is to stay under 1,000, which 43% achieved.)

The start time to render the first view averaged at 0.94 seconds.

The time for the fully loaded first view averaged 2.64 seconds.

24 was the average number of total HTTP requests.

13.7 was the average number of image requests (making up 57% of total requests).

711 KB was the average of fully loaded email.

568 KB was the average weight of images.

Images accounted for 79.8% of an average email’s weight.

Image weight ranged from 9 KB to 4.4 MB, and 50% were 200 KB or under.

69.7 KB was the average weight of web fonts (9.5% of the email’s total weight).

30% used web fonts (Open Sans was the most popular, then Merriweather).

Originally, I included performance because I’d heard a lot about how web fonts can slow things down. Looking at the top 20 Google Fonts73, the average weight is 28 KB (WOFF) for one weight, and most people used three in this study, so they do add up (69.7 KB was the average size of a web font download). While web fonts are certainly something to keep an eye on, they accounted for 9.8% of the total weight; compare that to images, which accounted for 79.8%.

As Guy Podjarny notes74, images are where most of the bloat resides. One helpful tool you might have overlooked is Litmus75, which tells you the number of images, the size and the time to load when you run an email preview.

76Images accounted for 79.8% of an average email’s weight (568 KB was the average image download). (View large version77)

Performance is as much a cultural problem as it is a technical one. It’s an abstract concern — out of sight, out of mind. I’ve been experimenting with incorporating performance budgets78 into our process to address this, but it’s a work in progress. Lara Hogan of Etsy tweeted Etsy’s performance wall79, which helps them “feel the difference on mobile connections.” WebPagetest, which I used for the performance section of this study, generates videos and filmstrips80 that helps clients visualize how their emails load.

81According to Filmstrip, H&M’s email took 4.095 seconds for its start rendering time (i.e. the point when something starts to appear on screen). (View large version82)

Originally, I wanted to explore what it was about websites like iA, Fray, Medium, and Pelican Books that made their typography so solid, and then try to incorporate any findings into guidelines for email design. Was there a consensus on body copy size and margins on mobile, for instance?

What I found from this study and from going back and looking at those websites is that there isn’t one set of numbers that’s going to work in every situation. As Tim Brown points out (in a video well worth the $1.99), good typesetting isn’t transferable because it depends on the typeface being used.

83While font sizes tend to keep within a certain range on the web, there’s still room for creative license. (View large version84)

However, this study does provide a decent starting point for designing emails: for example, using 16 pixels for body copy with a 24-pixel line height, which you can then adjust to suit the typeface and line length and on and on. The proportional relationships, the guideline to build out a custom responsive type scale that adjusts across viewports and some basic guidelines such as fluid line heights have proven the most useful.

It’s also worth looking at the resources tab in “Typographic Patterns in Email85” (a Google spreadsheet) because the additional reading was really valuable, and it lists many typography experts to follow. If you are a web developer, then a good place to start is Jason Rodriguez’s free chapter, “Typography in Email,” which will get you up to speed on the differences between the two disciplines.

Finally, here is a brief overview of the most important findings from the study. Please take them with a grain of salt: it isn’t necessarily wise to follow the trends out there; but it is important to keep in mind what other emails are like in general, so you can make yours more readable.

74% used sans-serif for their primary heading and 26% serif; 64% used sans-serif for their body copy and 36% serif.

15.7 pixels was the average desktop body font size; 15.58 pixels was the average mobile body font size.

623 pixels is the average width for desktop templates.

78.5 is the average number of characters per line on the desktop; 53.86 is the average number of characters per line at 450 pixels.

The measure ranged from 22 to 57 characters on mobile.

1.51 was the average desktop ratio between line height and body copy, dropping to 1.45 at 320 pixels.

The average line length divided by line height was 23.1.

76% left-align and 24% center their mobile body copy.

There were two primary groupings for headings on desktop: 24 to 26 pixels and 28 to 36 pixels

28.48 pixels was the average size of primary headings on mobile (320 pixels).

12.3 pixels was the average size for pre-header text on desktop; 12.9 pixels was the average size of pre-header text on mobile.

2.0 was the average ratio of body copy to primary heading (31.6 and 15.7).

The ratio of desktop pre-header text to body copy was 0.78; the ratio of mobile pre-header text to body copy was 0.85.

jim pallett

that email clients specifically block the technologies that you need in order to make something responsive.

that if you try ANY “reponsive email” technology out in the real world it will fail on approx 50% of the devices that receive it.

that anything that claims to do so is just marketing guff aimed at marketing folk who don’t understand the technicalities – and who on’t actually TRY the result on anything expect their ipad and iphone (because it’s quite easy to get something that works well on ONE device-type, but that’s the total polar opposite of “responsive” ethos ) – but that this site has a technical audience who DO know that what you’re talking about is impossible.

-22

3

Vitaly Friedman

I respectfully disagree, Jim. Responsive email is pretty much possible, and you can use a number of techniques to make responsive emails work well across a plethora of screens. Our own newsletter is very much responsive, and here are a few clever workarounds to make it work even with more complex layouts: http://www.responsiveemailpatterns.com.

It isn’t easy, and it’s very dirty and a bit crazy, but you can make it work.

7

4

Anna Yeaman

It’s true that responsive design doesn’t have universal support, but many email programs have enough of a mobile audience to make it worthwhile. You can have a solid experience in both desktop clients like Outlook that don’t support it, and iOS/Apple Mail/Android that do (though yeah Android is a bit hit and miss support-wise). If you really want to get dirty check out Nicole Merlin’s tutorial on dealing with apps like Gmail that don’t support media queries.

B. Moore

Hells Yes you can make responsive emails but I warn you it is a time consuming pain in the ass.

If you take the time to code it right and test, test and test again with tools such as EmailonAcid you will notice a Significant difference in your open/read stats or conversions or what ever metric you use to decide if the email failed or not.

Elliot Ross

Yes Jim, thanks for Emailsplaining that. We are all well aware of the technicalities of responsive email.

There are multiple techniques you an use (in tandem) to achieve responsive email across almost all platforms. The first approach is to use media queries. That gets you a great experience where it’s supported, which is mainly iOS and a handful of Android clients.

There’s then the Hybrid Technique (google ActionRocket Hybrid Technique), which is akin to fluid coding on the web, where you build your email to be 100% wide. That achieves good mobile support where media queries aren’t supported, typically Gmail app on Android and iOS.

Lastly there’s a couple places (Outlook & Apple Mail) where you have to do some fruity stuff to stop a 100% wide email becoming too wide, which involve some Outlook conditional queries and an additional media query.

Email design is hard. Arguably harder than the web is, thanks to the fragmented nature of email clients and their wide variance of HTML support.

It’s true that there are definitely sales people who will promise the world and that “responsive works everywhere”. But there is a growing community and industry that is pushing the boundaries of email and driving innovation.

2

9

Jerry

Anna Yeaman

Scott Brown

All this talk of fancy fonts (well, ones that are non standard in Windows) and responsive layouts is all well and good if you’re not working for a B2B company where 95% of people open their e-mails in Outlook where you can do next to nothing, let alone call in @font-face.

It’s still 1999 in my e-mail design world, I’m sad to say, and may others I expect. God know why MS decided Word was a sensible rendering engine for e-mails.

4

12

Anna Yeaman

it doesn’t look as though we’ll see the back of Word anytime soon, though they were asking for feedback from the email community on how to improve it just recently. Good news is Outlook’s marketshare is decreasing (Litmus reports a 30% drop in the last 12 months), though there are still some B2B companies like yours with big numbers. 95% Outlook is rough, though at least we’ve had years to get used to its quirks. Obviously mileage varies, we’ve had clients with 70%+ mobile, once you know what you are dealing with you can decide which tactics to adopt or ignore.

0

13

Scott Brown

Mobile is slowly creeping up but people tend to be at their desks when it comes to the clients of the firm I work for. I have 3 possibilities: MS get their act together and use something sensible for rendering HTML in Outlook, more and more people use their phone/tablet for e-mail (and even then, it will never be the majority) or something comes along that blows MS Office away. Nothing short-term there is there?!!

Still, the way I do it now is the way I’ve done it for nearly 10 years as a web pro so I know the ins and outs. The thing is that 10 years ago Outlook used IE to render e-mails. Not ideal but certainly better!

0

14

Jason

I respectfully disagree. The traditional “at the desk” open assumption and work hour distribution timing is a thing of the past. In a recent campaign (30K recipients) iOS devices alone accounted for 51% of opens – the iPhone 41%.

We’re fortunate enough to have some rather progressive clients who allow us to experiment with distribution times, design alternatives and content. Speaking specifically to travel, hotel and hospitality campaigns (for destination markets) the open, and more importantly conversion rates are strongest post work hours (shockingly on Friday) and Sunday between the hours of 8am and 3pm. Our theory is that cleaning up the inbox has become a sort of Sunday News for a lot of 9 to 5’ers.

Meanwhile, Outlook (all versions) came in at 7%. Yahoo at 5% and AOL at 2%. A majority of that activity is, as you allude to done from the desk. However, from a design and creativity standpoint I will gladly sacrifice (to a degree) those users to design campaigns unlike anything else out there. Converting on just 1% more of the mobile / tablet users is roughly 420% better then the same 1% of the aforementioned 14%.

Jason

This was rather shocking to me. Then I looked at the spreadsheet. If you eliminate the 5 monsters on there around 2MB+, this drops to about 450K all-in w/ images. Something we tend to strive for as well. One thing I’ve noticed a lot of marketers and designers failing to do is compress their imagery – something that can usually halve the size of an email.

Given the importance of mobile campaigns it’s interesting more designers and companies don’t implement a self-imposed ceiling in their content size and designing accordingly. One would think that with the rather singular (and easily trackable) conversion goal of email marketing and the importance of accessibility across devices / chance of lackluster connectivity there would be more significance placed on keeping those campaigns small(ish) w/o sacrificing design.

0

17

Anna Yeaman

Some email devs are automating their workflows and part of that involves image compression. Like you I also noticed that some weren’t taking the time. Sure that stat would go up if you consider the use of animated Gifs in retail emails, I think only a few in this study used Gifs like Maker.

0

18

Bhushan Kulkarni

Very helpful thoroughly researched article Anna. Such articles give better insights to email marketers to see whats coming from the other side. Ariticmail believes in making the e-marketing expirience better and better for the readers and this read will definately help a great deal.

Today, too many websites are still inaccessible. In our new book Inclusive Design Patterns, we explore how to craft flexible front-end design patterns and make future-proof and accessible interfaces without extra effort. Hardcover, 312 pages. Get the book →

Meet the new Sketch Handbook, our brand new Smashing book that will help you master all the tricky, advanced facets of Sketch. Filled with practical examples and tutorials in 12 chapters, the book will help you become more proficient in your work. Get the book.

Meet SmashingConf San Francisco 2017, featuring front-end ingredients, UX recipes and nothing but practical beats from the hidden corners of the web. Only practical, real-life techniques and recipes you can learn from. Get your ticket now!