You might of heard of bulletproof guides for background images and buttons in email design, but what about the basics of using images? Due to varying level of HTML/CSS support in email clients, embedding images in email templates isn’t as easy as you’d think. I’ve decided to compile all of the information and potential problems with images in email design and how to maintain compatibility with various email clients.

Set a sensible doctype

First and foremost, set a doctype, if you don’t you’ll be at the mercy of Quirks mode, and that isn’t a fun type of rendering to be under. Older HTML doctypes like 4.0 also can produce weird results. What doctype should you use? Good question. Generally its up to the email developer but I would personally recommend XHTML 1.0 Transitional.

Why XHTML 1.0 Transitional? Because it allows you to be the most compatible and W3C valid as its going to get. Some email developers suggest alternatives like XHTML 1.0 Strict or HTML5, however I think XHTML 1.0 Transitional is the way to go, because its valid to use attribute properties on various tags where as XHTML 1.0 Strict and HTML5 generally deprecate them and encourage the use of CSS properties, this isn’t necessarily going to be possible in all email clients. Lets face it, coding email templates isn’t exactly elegant.

You can actually use HTML5 features like video under the XHTML 1.0 Transitional doctype. Who knew, right?!

Image gaps

This is one of the most common problems you can face with images in email design. The cause of this behaviour usually stems from email clients that use the HTML5 doctype, which is used in more email clients than you might think. What happens is an image will have gaps around itself making the image element take up more space that is intended. Sometimes you can get away with this issue, but when you are stacking images on top or adjacent to another (image slicing) or going for pixel perfect design this is a problem.

Make all images block elements

By making an image a block element you will neutralise the gap issue in most clients.

The main property to watch is -ms-interpolation-mode as it potentially helps solve problems with the appearance of images that are being resized via attributes in older versions of Internet Explorer. However you shouldn’t really be doing that, as explained above.

Declaring width and height on images

Here’s a question that many ask when using images in email designs, should I be declaring width and height attributes on my images? A good question. The majority of the time, yes you should. The reason for this is because some clients will invent there own dimensions if nothing has been set. You should never really leave it up to the email client to define the size of the image, as you can get strange image off layout appearance in some clients. Declaring both a width and height which is exactly the same as the actual image size is will maintain compatibility.

You should also never use the width/height attributes on images to “resize” an image either. The reason for this Outlook clients will use the size of the image as is, regardless of what attributes are set.

A notable exception to this rule would be if you wanted to use a fluid approach layout with a large “hero” image, in this case you should define a width but not a height, otherwise you might find odd resizing going on for clients that don’t support media queries where you can’t override the height.

Minimum cell height for Outlook 2013

No email client quirks write up is complete without a mention of Outlook, and guess who’s joining the party with this entry. Outlook 2013 has a minimum height for table cells which is approximatively 15px – 20px. This means if you have an image that’s smaller than 15px within a table cell, you’ll find gaps suddenly appear. In order to prevent this you need to use both the height attribute and line-height property on the containing table cell

Outlook 2007 and its successors generally don’t do line-height very well, if you stumble upon strange issues with line-height, try using the MS Office specific property of mso-line-height-rule:exactly; to get it to play nice.

This isn’t limited to the minimum cell height issue, you can apply this to table cells with larger heights as well. You should include this MSO specific property before the actual line-height declaration.

Additional defensive coding for Office 365/Outlook Web App

You’ve mastered Outlook but now this really is the boss level. Office 365 a.k.a Outlook Web App, is Microsoft’s webmail type offering, aimed at businesses and the enterprise segment. It might well be a web app but its standards aren’t even close to such.

When turning an image into a block element fails

Sadly, the display:block; fix method near the beginning of this article only goes so far. Office 365/OWA are special cases and have pre-processors that are jacked up on destroying everything good about email design. The reason being they have an egotistical nature of stripping virtually any inline styling off images (and other elements too!).

Even Jessica Alba is shocked by the email rendering in OWA.

In order to increase compatibility, additional defensive measures needs to be applied to image content.

This is a method to basically satisfy the pre-processor of OWA, because its about as close to display:block; as you can get. Because a div is a block element by default, wrapping an image with one essentially does the same thing. By setting a height equal to the image height size this will remove gaps.

Something I noticed in addition to the original Email on Acid article is the wrapping an image in a div trick doesn’t always nuke all the gap space depending on the CSS properties used on its parent container (likely a table cell). One of the main issues was when line-height was used. Because of this, the height would ever so slightly be larger than the original pixel value, undoing the work of the div wrapping fix. However in order to maintain this fix while using line-height, you can add font-size to the parent container of the div.

Its debatable as to how drastic using font-size in this way can be from a spam score point of view, but it certainly isn’t healthy. It should really only be used if the standard wrap an image in div method doesn’t quite work on its own, which I have noticed occur in a few OWA/Browser combinations based on the example above.

Kill the hyperlink borders!

This is something made famous by older versions of Internet Explorer, but can occur in other clients as well. Whenever you hyperlink an image it creates a “lovely” blue border around the image. It can be problematic however when doing pixel perfect design, as the border will add tiny bit more size to an image element. Fortunately, its an easy fix and there are essentially two ways to go about it fixing it

Which one should you use? Personally I would say the first example with the border attribute. The reason for this is because HTML attributes have better compatibility and tend to survive email client pre-processors. The use of the CSS border property does exactly the same thing, but it is more at risk from being stripped.

Fix the scaling of images in Outlook

DPI and Outlook are two words that have never made a lot of sense when it comes to rendering email. Certainly for Outlook 2007 and above, images tend to not render correctly along with widths and heights not being properly interpreted when using a DPI setting that’s greater than 96 DPI (100% scaling). Unfortunately the problem is rather detailed and complex, hence I wrote separate a completely separate article detailing all of the dirty details. However in the case of images, this snippet can do wonders.

This one has to win the quirk of the year awards, because it quite frankly makes no sense. The Windows 8 mail app is the touch optimised email client for Windows 8. Most likely to be used by Surface tablet users, or any touch screen Windows RT/Windows 8 device. The client itself is simple, yet functional and has excellent standards support, but just don’t talk about the background-size CSS property.

For whatever reason, this email client doesn’t like have background-size expressed in its single property declaration, yet its OK when you use the shorthand variant.

Here’s a few CSS examples that can catch you out with the Windows 8 mail app:

Why does the third test work but not the rest? Because the Windows 8 mail app strips background-size when its on its own, but won’t strip/modify the background property at all. Meaning if you use the background property and combine all the various background properties values in one go, your safe. What’s interesting however is every other CSS3 client will render all three examples no problem. Further food for thought, the rendering engine of the Windows 8 mail app is Internet Explorer, and Internet Explorer doesn’t exhibit the same issue, therefore this is purely down to the Windows 8 mail app pre-processor. Maybe one day someone from Microsoft can explain this bizarre behaviour!

Images off? Don’t panic. Alternative text is your friend

With all this talk about images, another thing to remember is not everyone sees them by default. This can be down to user preference or due to the default behaviour of the email client. This means its important to develop an email layout that still makes sense for when images are off. There are several techniques you can use to cater for this situation.

Set background colours as fallbacks to visually indicate something is there when images are off

Use styled alternative text to still get your message across via text

Alternative text is something you should already be aware of from a general accessibility point of view, but in email it goes a lot further.

Styling alternative text is simple, apply styling attributes to the image to create better image off appearance. This can include colour, font and the style of the font.

Share This:

I know Outlook *used* to blow up images to full size and ignore resize tags, but I don’t see it happening in any version of Outlook anymore when I test. Have they addressed this? (Still a bad idea to send a 2MB image in an email, which takes forever to load, but still, would be an improvement!)

Interesting point. I just tested Outlook 2003 – 2013 with various Windows Virtual machines ranging from Windows XP to Windows 8.1 each running a version of Outlook on each, it appears that Outlook does indeed honour width and height attributes on images, but only if you are trying to scale down the image from an original size, say 300×300 to 150×150

What problem still remains is the upscaling of a smaller image to a larger size with attributes. Say for example, using a 1×1 spacer GIF (which is an old example) but illustrates the problem quite well, this article explains it all nicely:

This is when you get into trouble with Outlook, and doesn’t appear to be limited to Outlook 2007, its latter versions exhibit the same behaviour, lovely Word rendering engine I suspect.

Overall, I’d still recommend using image attributes and declaring a width/height (width as being essential), because image off appearance can be really funky without them. I’ve seen many email clients shrink nearly the entire space where an image should be and even the complete opposite where by the vertical height of the image being increased by about 2x when images are off. While the layout will be fine with images on, you have to be mindful of the initial view that some users get.

Jessica Best

Agree that attributes are still a good idea, but glad to hear that (maybe) the blow-out issue is resolved. The spacer resizing is a rare tactic on our end, but a good note to make. Thanks for digging into this on your end! Glad to see our tests “match”.

Meant to reply to this ages ago – thanks for the insight and testing feedback!

Jaina

Great run down here, James – bookmarking for future reference!

Something I’ve noticed is if I want to center align an image, having display:block won’t let it happen. But display:inline-block will allow that image to be aligned in the centre of whatever element it’s in. Though, is inline-block well supported? I know it’s been a bit spotty in the past.

This should allow you to centre an image that’s a block element, without having to change the display property.

Hope it helps!

Jaina

Cheers James! Always forget to just wrap images in other block level type elements and apply the style property to it. Simple solutions work best!

SarahC

Thanks for the tips James.

I was wondering if anyone had fixed the spacing-under-images issue in OWA, without resorting to specifying image height in a div? Although setting with image to an absolute height solves the problem in OWA, it ruins any responsive design by adding massive gaps in mobile.