Many emails are designed with a large screen in mind. Text that looks great on a large screen can be difficult to read on a mobile device, though.
If Gmail deems that the font-size of any text in an email is too small to be legible, it will increase the size and flag the message with this notice:

That’s pretty nice. What could have been illegible is made legible, eliminating the need to pinch and zoom our screens.
It can also be a little frustrating. As designers, we often have a preference for how our code renders. Having a third party step in and hijack the design might feel a little dirty, or it could even break an entire layout if Gmail gets it wrong.
A legitimate argument could be made that Gmail should simply support media queries if it wants to improve legibility. Give us control to create a better reading experience, right? Unfortunately, Gmail doesn’t support media queries.
Let’s take a look at what triggers this functionality and a few methods for overriding it.
What triggers the font-size bump-up?
Gmail appears to search specifically for elements in the email that are wider than the screen being used to view the email. For example, if Gmail notices that a table
element is 600px wide but the current screen is only 320px wide, the app will bump up the font-size up by as much as 50%.

If the table
element is within the bounds of the screen, then Gmail will display the email as it was designed. For example, the same email that gets bumped up might actually display normally if the device is rotated to landscape mode.
Three ways around this
Some emails may actually benefit from an increased font size. Others, however, may benefit from preventing the font size from changing at all. In these cases, there are a few methods from stopping Gmail in its tracks.
white-space: nowrap
Method 1: Using Justin Khoo offers a clever technique:
I found out that if the
white-space: nowrap
style is applied to text and if increasing the text size would cause the email width to be widened beyond the window width (causing the email to look really bad), that Gmail somehow senses it and backs off on applying the font-size change.
The idea is to create a non-breaking string of characters such that if the font-size were increased, it would cause the characters to spill outside the container and prevent Gmail’s functionality from being triggered.
That winds up being a snippet placed inside the widest element in the HTML that looks something like this:
<div style="display: none; white-space: nowrap; line-height: 0; color: #ffffff;">
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
</div>
Gmail ignores the display: none
style. Then white-space: nowrap
tells Gmail not to break the text into multiple lines, which forces Gmail to stop the font zoom.
The goal is to get a line that is just short of the width of the container. And the color should be matched to the background color, so it’s invisible.
A few concerns have been raised that using invisible text in an email could cause it to be flagged as spam. It’s certainly worth consideration when attempting this method and to test it in as many clients as possible.
Method 2: Use a spacer image
We can add a row to the top of the table
that acts as the email container. Let’s say that container is supposed to be 600px.
...
<tr class="gmail-fix">
<td>
<table cellpadding="0" cellspacing="0" border="0" align="center" width="600">
<tr>
<td cellpadding="0" cellspacing="0" border="0" height="1"; style="line-height: 1px; min-width: 600px;">
<img src="spacer.gif" width="600" height="1" style="display: block; max-height: 1px; min-height: 1px; min-width: 600px; width: 600px;"/>
</td>
</tr>
</table>
</td>
</tr>
...
What we’ve done is created a row at the top of the table that embeds an image and forces the layout to 600px. Gmail will recognize the table as 600px and is now unable to shrink it down, which prevents the text from zooming.
Then, we can hide this row on clients that support media queries by adding CSS to the <style>
section of the document head, which is ignored by Gmail:
/* Hide spacer image in applications that support media queries */
@media only screen and (max-width: 600px) {
*[class="gmail-fix"] {
display: none !important;
}
}
Please note that while this method did hold up in tests, there have been reports that it is not a universal fix for all email clients. The key, as always: test, test, test.
!important
Method 3: Declare This is likely the easiest method:
...
<td>
<p style="font-size: 13px !important;">The text</p>
</td>
...
Gmail will respect the !important
declaration on inline styles. The !important
declaration gets a bad wrap in CSS, rightfully, because it applies the style so forcefully that it is hard to override. That’s a problem when you are building a site you have to maintain over time. But emails aren’t like that. They are one-offs with very short lifespans. A styling no-mans-land where nothing is off limits!
One thing to keep in mind here is that Outlook 2007 will ignore elements styled inline with !important
. As a workaround, we can include this CSS in the <style>
section of the document head:
p {
font-size: 13px !important;
}
Wrapping Up
Gmail’s technique of increasing font sizes in email is a double-edged sword. On one hand, it’s a nice enhancement in those cases where emails clearly designed for desktop become easier to read. On the other hand, the “enhancement” might hurt our carefully crafted designs.
Each of the overriding methods we covered comes with advantages and drawbacks. Is one better than the others? Have you tried a different method? Please share in the comments!
How very Microsoft-y of Google to do this.
Remember “Do no evil?”
I think it’s a tad unfair to categorize this feature as “evil” and that certainly was not the intent of the post. I hope it didn’t come across that way.
I do tend to see the text zoom as a step in the right direction. It can make emails much easier to read and that’s an improvement in user experience. Love it or hate it, but the people reading the email are Gmail’s users as much as they are the users of the people sending the email.
At the same time, there are clearly things that could be better about the feature. We covered some of those points in the post, but a separate post could be written altogether that debates those points and, ultimately, who owns the user experience: Gmail or email designers.
Either way, I hope the intent of this post (tricks for overcoming the feature) are primary to any gripes (opinions about the feature).
I’ve always said that building emails is worse than building for IE6. Hack and slash, just like in WOW :p
On the other hand, for those that do not know the reason we use
!important
in the selectors inside the media query block is because without it Yahoo! Mail on desktop likes to use the classes in the media query block to display the email. In other words, it shows the responsive version on desktop.Or it used to. A few weeks ago Yahoo! Mail Fixes Media Query Bug.
—
Pretty interesting techniques there. I’ll probably stick with the
!important
one.After designing emails for a while, the one recommendation I can give others is: Keep it simple and, if possible, try to avoid two column layouts. The headaches trying to make the columns 100% wide in small screens is not worth it. Focus on your design and make sure the message comes across properly within a single column layout. Something that has such a short life span and with the vast majority of email clients being so behind in supporting modern web technologies, it’s not worth spending huge amounts of time trying to please every email client.
Very interesting write up, Thanks for sharing.
Actually, it’s not the use of
!important
that was for Yahoo! Mail.!important
is used to override the CSS for desktop that are required to be inline in the HTML because certain email clients (coughGmailcough) don’t support CSS in the<head>
. So the CSS in the media queries for responsive emails needs!important
.The Yahoo! Mail fix was actually the use of the “Attribute Selector Hack” in the link you provided (ie.
td[class="myclass"]
), instead of using the regular CSS class selector (.myclass
). The attribute selector is what prevented Yahoo! Mail from displaying CSS within media queries meant only for mobile on desktop, not!important
. Until of course their fix released recently.Crap, I got confused there for a bit. Indeed the Yahoo! Mail hack is the use of the attribute selector rather than
!important
.Not anymore though. One less thing to worry about.
I hope an email client war breaks soon, lol.
This is weird coming from gmail while Yahoo is “improving” day to day.
https://www.emailonacid.com/blog/details/C4/yahoo_mail_now_supports_media_queries
It’s always more work for us anyway…
Great article btw, thank you
Thanks for the mention! I’d like to add that the
white-space:nowrap;
technique works best using a monospaced font (ie. courier) since it gives the spaces more width.The concern about spam filters is justifiable, although most ISPs these days put more weight in other signals such as user engagement.
Wanted to add that I believe this only happens on Gmail’s iOS client and not Android, where most of the Gmail mobile app’s userbase is at.
Hey Justin!
Nice call on using a monospaced font. That would certainly make the width of the line more predictable, especially in cases where the fix is being applied to multiple emails or templates with varying designs.
I think you’re correct about iOS, but also encountered the font zoom in the web app as well in Mobile Safari.
Great work on the fix! I definitely found it useful and effective.
I have noticed that the trick for Gmail for iOS does have an effect on Gmail for Android. Depending on the email, you can get away with using less dashes for the hack. Otherwise, it can have a “zoomed out” effect on the email in Gmail for Android, and the email won’t fill the width of the mobile device’s screen as much as it should.
How do you implement the !important inline without breaking Outlook? You say to put it in the style section, but Gmail ignores the head. How are you implementing it?
Plain text e-mail > .*