Can Email Be Responsive?

Love it or hate it, there’s no denying the popularity of HTML emails. And, like the web before it, the inbox has officially gone mobile—with over 50 percent of email opens occurring on mobile devices.

Article Continues Below

Still, email design is an outrageously outdated practice. Remember coding before web standards became… standards? Welcome to the living hell of email design.

But coding an email doesn’t need to be a lesson in frustration. While email designers still have to build layouts using tables and style them with HTML attributes and—gasp!—inline styles, a number of intrepid designers are taking modern techniques pioneered for the web and applying them to the archaic practice of email design.

Building on the principles of responsive web design first codified by Ethan Marcotte, a revolution in email design is giving birth to an experience fast approaching that of the modern web. Subscribers need no longer be subjected to terrible reading experiences, frustrating touch targets, and tiny text.

The value of HTML email#section2

Whether or not you like HTML email, it is a vital tool for nearly every business. When it comes to marketing, email consistently outperforms other channels like Facebook and Twitter. More importantly, email allows you to interact with a potentially massive audience in an increasingly personal way.

You may not actively engage in email marketing, but chances are that, as a web designer or developer, you use email to communicate with users on a regular basis. It could be sending a receipt, updating users on a new product feature, or letting them know about your latest blog post. Whatever the reason, email is an important and often overlooked medium.

Many developers choose to send customers plain text email. While plain text has many benefits (easy to create, renders everywhere, downloads quickly, etc.), HTML email has a number of advantages:

  • Hyperlinks. You can link out to landing pages from an HTML email and build traffic and engagement.
  • Design. A well-designed HTML email lets you reinforce your brand, even in the inbox.
  • Hierarchy. You can build hierarchy within HTML emails and more easily call attention to important copy or vital links.
  • Tracking. HTML email allows you to track opens and engagement—valuable data that can be used to optimize your marketing efforts.

By not giving email as much attention as your pixel-perfect app, you are effectively losing out on 1) a valuable branding opportunity, 2) the ability to track opens and interactions in your emails, and 3) the opportunity to provide an amazing user experience outside of your application.

HTML email sucks#section3

Designing and developing HTML email has traditionally ranked among the worst experiences for any web designer. It’s like getting into a time machine and stepping out into a hellish ’90s world of table-based layouts, inline styles, non-semantic markup, and client-specific hacks.

Here’s just a small sampling of why HTML email can be a pain:

  • No Standards. Sure, we use HTML and CSS. But not like on the web. No real standards exist between email clients, leading to some crazy code.
  • Email Clients. Email clients, like Outlook and Gmail, all render HTML and CSS differently, often outrageously so. Which leads to…
  • Lots of hacks. Even well-designed email campaigns need to rely on client-specific hacks to make things work.
  • No JavaScript. The web’s favorite language has no place in email, as email clients (rightly) strip it due to security concerns. Goodbye interactivity.
  • Inline styles. I’d love to separate structure from presentation. Unfortunately, most email clients force you to rely on inline styles and attributes for nearly everything in email.

While things likely won’t change anytime soon, there is a movement in the email design community (yes, one does exist) to alleviate the misery normally associated with developing email campaigns. A number of companies and individuals are improving the tools and methods of email design, and sharing their knowledge more than ever before.

The company I work for, Litmus, is one of them. We build instruments to make testing and tracking email campaigns as painless as possible. And we’re all-in on spreading information about email marketing in general, and email design specifically. We even started a dedicated community to connect email marketers, allowing them to share their knowledge, refine techniques, and learn from both us and each other.

While I reference some of Litmus’ tools and resources in this article, there are a number of other companies and people working hard to improve the art of email design. In particular, both MailChimp and Campaign Monitor have excellent blogs and guides. And people like Anna Yeaman, Nicole Merlin, Fabio Carneiro, Elliot Ross, and Brian Graves are all working to make email design a true craft.

The changing inbox#section4

Just like the rest of the web, the inbox is becoming mobile. In 2013, 51 percent of users opened emails on mobile devices. That number is likely to increase, especially considering that a growing number of people rely on their mobile device to access the internet, both out of habit and necessity.

The good news is that web designers can adapt their existing skills and apply them to email campaigns, creating a beautiful user experience on a channel vital to most users, but ignored by many designers.

How HTML email works#section5

Generally speaking, HTML email is just like designing a web page—assuming web design has no knowledge of anything post-Designing with Web Standards. HTML emails rely on three things: tables, HTML attributes, and inline CSS. As you learn to build HTML emails, keep in mind that, due to email client rendering engines, we are working with a very limited subset of HTML and CSS. Campaign Monitor maintains an excellent chart of what CSS is supported across major email clients.

Let’s briefly go over the basics of HTML email before looking at how to make emails responsive. As an example, I’ve adapted the template we use for our own newsletters at Litmus. Thanks to both Litmus and our wonderful designer, Kevin Mandeville, A List Apart readers can learn from and build on the same code we use for most of our campaigns—it’s now hosted on the A List Apart Github account. To see how it performs across clients, you can check out the full range of Litmus tests.


Most web designers use tags like the div, header, section, article, nav, and footer for building the structure of web pages. Unfortunately, email designers don’t have the luxury of using semantic elements. Instead, you *have* to use HTML tables to lay out your email campaigns. These tables will be nested… deeply.

Basic styling of tables will largely use attributes that most people haven’t used in quite some time: width, height, bgcolor, align, cellpadding, cellspacing, and border. Coupled with inline styles like padding, width, and max-width, designers can build robust email layouts.

Here’s an example of what a well-coded table in email looks like:

<table border="0" cellpadding="0" cellspacing="0" width="100%">
		<td bgcolor="#333333">
			<div align="center" style="padding: 0px 15px 0px 15px;">
				<table border="0" cellpadding="0" cellspacing="0" width="500" class="wrapper">

You can see how we nest tables and use the border, cellpadding, and cellspacing attributes to ensure that there aren’t unnecessary gaps in the design. A bgcolor is applied on the table-cell level, which is a more reliable method than background or background-color (although background-color does have its place).

One interesting thing to note is that a div is used to center the nested table and provide padding around the content. While tables should make up the bulk of your structure, the occasional utility div is useful for aligning content blocks, providing padding, and setting up some basic styles. However, they should not be used as the main structure of an email since most email clients have trouble with at least some aspect of the box model, making it unreliable for laying out emails.


Using images in email is very similar to using them on the web, with one caveat: a number of email clients disable images by default, leaving subscribers looking at a broken, confusing mess.

An email with images disabled

While there is no way to automatically enable those images, we can improve the situation by using alt-text to provide some context for the missing images. What’s more, we can use inline styles on the img element to style that alt-text and maintain some semblance of design.

<img src="img/fluid-images.jpg" width="240" height="130" style="display: block; color: #666666; font-family: Helvetica, arial, sans-serif; font-size: 13px; width: 240px; height: 130px;" alt="Fluid images" border="0" class="img-max">

Using the code above, our missing image now makes a bit more sense:

Alt-text goes a long way


One of the main advantages of HTML email is the ability to include clickable hyperlinks. Beyond just including links within copy, HTML email allows you to use big, beautiful buttons to entice subscribers.

Many email marketers use linked images for buttons. However, using bulletproof buttons, designers can craft buttons via code that renders reliably across clients, even with images disabled.

The table below is an example of an all-HTML bulletproof button, which uses borders to ensure the entire button is clickable, not just the text:

<table border="0" cellspacing="0" cellpadding="0" class="responsive-table">
		<td align="center"><a href="//" target="_blank" style="font-size: 16px; font-family: Helvetica, Arial, sans-serif; font-weight: normal; color: #666666; text-decoration: none; background-color: #5D9CEC; border-top: 15px solid #5D9CEC; border-bottom: 15px solid #5D9CEC; border-left: 25px solid #5D9CEC; border-right: 25px solid #5D9CEC; border-radius: 3px; -webkit-border-radius: 3px; -moz-border-radius: 3px; display: inline-block;" class="mobile-button">Learn More →</a></td>
Bulletproof buttons look great with images disabled

Once you have those basics down, it’s time to see how we actually make an email work well across a range of device sizes.

How responsive email works#section9

Just like with responsive websites, there are three main components of a responsive email: flexible images, flexible layouts, and media queries.

The only difference between the web and email is in how these three techniques are implemented.

In email design, we have a limited subset of HTML and CSS at our disposal. We can’t rely on properties and values that designers use for responsive sites on the web; margins, floats, and ems don’t work in many email clients. So we have to think of workarounds.

Flexible images#section10

Fluid images aren’t too tricky. Although they use the width property set to 100%, some clients have trouble rendering images at their intended size unless the width and height are defined using the corresponding HTML attributes. Therefore, we have to build them to specific dimensions and knock them down later.

The first step is ensuring that images are robustly coded. Let’s look at our image of the email screen from earlier.

<img src="responsive-email.jpg" width="500" height="200" border="0" alt="Can an email really be responsive?" style="display: block; padding: 0; color: #666666; text-decoration: none; font-family: Helvetica, arial, sans-serif; font-size: 16px;" class="img-max">

Notice that display property that’s included? It’s just one example of the many hacks required to deal with naughty email clients, as is the border attribute. Most webmail clients add space around images in an attempt to fix line-height issues that may arise. Making images block-level will kill that spacing and save your design.

Now, when we want to make our images fluid, we can do so in a media query in the head of our email:

img[class="img-max”] {
	width:100% !important; 
	height: auto !important;

Not every image will need to be fluid. Elements like logos and social icons typically stay the same size regardless of device size, which is why we target flexible images using a class.

Since we will always be overriding inline styles and HTML attributes, the important declaration is used to ensure that our responsive styles take precedence when the document is rendered.

Let’s jump into something a bit more difficult.

Flexible layouts#section11

Most web designers are familiar with building responsive designs using semantic elements sized with relative units like percentages, ems, and rems. While we can still use percentages for flexible layouts in email, they will be used inline on tables and subject to a few limitations.

Nearly all of our tables will use percentages for their widths. The one exception is a container table with specific pixel dimensions to constrain the overall width of the email design to prevent it from blowing out in clients that don’t handle percentages well, typically most versions of Microsoft Outlook.

Let’s start with the container table:

<table border="0" cellpadding="0" cellspacing="0" width="500" class="wrapper">

You’ll see that we use the width attribute to force the table to be 500 pixels wide.

This container will hold every other nested table in the email. Since it will constrain everything to that 500-pixel width, we can safely use percentages to size our other tables.

But what good are flexible tables if the email is always 500 pixels wide? Take a look at that container table again. Notice that I included a class of wrapper. We’ll use that selector to make our emails truly responsive using (what else?) media queries.

Media queries in email#section12

Media queries in email work just like in web design. By including them in the head of your email, you can target specific device attributes and adjust your styles accordingly.

Keeping things simple, we’ll target viewports with a max-width of 525 pixels and below. Then, targeting that wrapper table, we can override those HTML attributes and inline styles to force the table to be the full width of the screen on mobile devices.

@media screen and (max-width:525px) {
	table[class=“wrapper”] {
		width:100% !important;

We can also target any nested tables and do the same—effectively stacking content sections for an improved mobile experience. It’s not a bad idea to bump up the size of text and buttons on mobile, either.

@media screen and (max-width:525px) {
	body, table, td, a {
		font-size:16px !important;
	table[id=“responsive-table”] {
		width:100% !important;

The main drawback of using media queries is that they are not supported everywhere. While WebKit-based email clients like iOS Mail and the default Android email app work well, older Blackberry devices, Windows Phone 8, and the Gmail app on every platform disregard media queries.

Fortunately, iOS and Android make up the majority of mobile email audiences, so you can rely on most subscribers seeing your responsive emails as intended.

Explore email design#section13

The techniques described above are just the beginning. Intrepid email designers are exploring the use of web fonts, SVG, and CSS3 animations in email. Sure, email design is hard and things break constantly, but that shouldn’t prevent you from exploring advanced techniques to see what works for you and your audience.

My one recommendation is to test the hell out of any email you build. Email clients are far worse than browsers in terms of rendering and support for HTML and CSS. Testing both on devices and using an email preview service—be it Litmus, Email on Acid, your own device lab, or something else entirely—helps identify problems and allows you to work out issues before sending to a million subscribers.

Aside from testing your code and rendering, track all of your emails and test what kind of content, copy, design, and sending cadence resonates with your audience.

Above all, don’t disregard email design. It’s a necessary evil, but it’s getting better all the time. A community is finally forming around email design, and techniques are constantly being refined and perfected. Responsive email design is one of them. If you really care about your product and presence on the web, you will take the passion and craft you apply to your app’s interface and transfer it to one of the most widespread and valuable mediums around.

54 Reader Comments

  1. Many email clients including Outlook and Gmail make plain text URLs “clickable”, it is not entirely accurate to claim this as a specific advantage over plain text.

  2. Being that emails are a huge part of the fundraising world for nonprofits, this article is a great one for designers who need to sharpen their email skills.

  3. Technically, you can make images always work by base-64 encoding the images and embedding them within the email. It’d make the emails huge, but this can be done if it’s absolutely critical for them to be displayed.

    Second, can we get some stats on how many people actually use the default email apps on android and iOS? Every I know uses the Gmail app. I know that is anecdotal but with so many people with Gmail and Google apps based email, and Gmail being pre-installed on Android I find that odd that most people would ignore it for the default app that’s buried away usually.

  4. Ok using the border on the bulletproof button is genius. I’ve been using the tool at to create buttons previously, but a quick litmus test shows that this works just about as well (a few quirks on outlook with the left/right borders) in terms of creating a button. Any idea why outlook doesn’t respect the stated border widths?

    Thanks for the tip!

  5. Obviously you would promote Litmus, which I also think is a great tool, if a little bit pricey. I’ve always found there is great documentation over at Their CSS Support is incredibly useful.

    Looking at that and then reflecting on this article, media queries are still a no go, right? I would like to see a design you’ve made, using media queries, go through the Litmus testing software. At least I’ve just resolved to using % based widths to handle smaller screen sizes.

  6. Hey Jason, great post! I recently wrote a post detailing my experiences building emails at Artsy, and covered a lot of the same topics you did (which is heartening to see). I also use Litmus quite a bit to test appearance of the finished layout in different mail clients to give me that confidence.

    Here’s my post (in case anyone is interested):

    Thanks for the great writeup Jason!

  7. I’ve been using Zurb’s Ink framework on a couple projects with a fair amount of success. For someone jumping into the world of email markup, this has been incredibly useful.

    I’m sure I’ll be forced to internalize every arcane rule and exception eventually, but Ink works well out of the box.

    Are there other frameworks or tools people have found useful?

  8. Matthew – what a great post on the Artsy blog! Great tips and I love seeing other designers’ workflows. Thanks for sharing!

    Matt – Brian Graves has an amazing collection of resources available at There are a ton of tools and frameworks mentioned, as well as various articles and presentations, too. Definitely worth checking out.

  9. @Jason Superb article, as usual! Email coding has definitely been a pain for years, and especially responsive coding (nowadays).

    We were fed up with it, and that’s why we are working on a drag and drop responsive email editor. It is really flexible and is based on basic elements like Title, Text, Image, Button.

    Would love to hear your thoughts about EDMdesigner!
    We are building it for you and ourselves to ease the “pain”.

    ps. We will feature this article in our next newsletter, that’s for sure.

  10. Courtney – Our former method is similar, but instead of using borders on the link, it uses padding on the table cell. It renders beautifully in Outlook (and damned near every other client as well) and you don’t have to rely on VML.

    The one downside is that the entire button is not linked, just the text inside. I honestly don’t feel like that’s a huge issue, but some people insist on the entire area of the button being linked.

  11. Jason,

    Great article. I am involved with creating pixel perfect email designs all the time and have found the following to be helpful.

    Thought I would share this recently discovered insight on resolving missing left side border in Outlook 2013 on


    I discovered recently that Outlook 2013 (not sure about previous versions) will not render the left border on a or . To resolve this, I use the following solution:

    Essentially you add an additional 1px width table cell using border-right on that cell. And then use another table cell next that that for the image table cell declaring the top, right and bottom border for that table cell.

  12. Jason – Yeah, I’ve done many buttons built that way, and is usually the go-to. Would love a workaround for the border restriction in Outlook, but I haven’t seen any discussion about it.

  13. Great article! Although I’ve been doing HTML emails for the past 2 years it’s good to see what others are using. In terms of mail client specific attributes, is this something you enforce or tend to leave aside as it is more code to cater for etc?

    Also, there are different ways of making an Email responsive; I work at Equator, a digital agency in Glasgow, and at the moment we have 2 main ways of making responsive emails and created our own templates based on these, but is there somewhere where we can see what other people are doing or even discuss best practices for this, even though there are no standards?

    Finally – Litmus is great! 🙂 learnt a lot from it

  14. Courtney – That’s interesting about the 8px max border in Outlook. In our own testing, we still see those borders just fine in Outlook. Admittedly, we haven’t measured if Outlook is trimming them down a bit, but the design still looks great (even without CSS3 border-radius).

    Paciencia – There absolutely is a great place to see what other people are doing and start up discussions on best practices! We just opened up our Community to everyone (re: you don’t have to be a Litmus customer to use it), and there are a ton of smart email designers in there sharing their knowledge.

  15. Can I just add that you forgot to change the arrow character in your example code to the html character? It should be & rarr ; (without the spaces) not →

  16. One caveat with the bullet-proof buttons: our campus email client (Groupwise 8, I believe) removes background colors, defaulting to white.

    So we have to be careful not to use white text–whatever color we use to contrast the button’s background needs to be dark enough to show up if the background color is removed, otherwise, we get lots of complaints from colleagues saying “you sent this out without x, y and z in it!”

    Otherwise, great article!

  17. This is a great article Jason. Thank you. As an email marketer that has adopted the Responsive Email Design paradigm, it is great to see all the available resources we have today. Litmus analytics are awesome and the email client testing they do is most helpful. The designers I worked with used that tool for testing purposes. I am very happy that Jason mentioned Anna Yeaman of @StyleCampaign in his article. She is my RED email sensei. Her RED video from March 2013 is still outstanding over a year later. I strongly urge you to watch this video and subscribe to their blog.



  18. Jason mentioned the that mobile email opens were over 50%. That is aggregated data for Litmus clients. Your clients will see something else. My experience has been all over the place depending on email, audience, day, time, etc. When discussing with marketers mobile email opens I like to use this data point —

    Ultimate mobile email usage stat:

    Mobile email will account for 15 to 70% of email opens, depending on your target audience, product and email type. eMailmonday- “the Ultimate mobile email stats” (2014)

    Source Link:

    This data point matches many real world mobile open stats I have been told in confidence.

    The link above is an aggregation of many email stats. I highly recommend it.

  19. Jason – Yeah it only appears to happen in Outlook 2007+. If the borders are quite large (say 15px) the difference is noticeable when comparing, though the button still looks okay – it’s not nearly as horrible as padding!

  20. Jake – Yep, there are always going to be edge cases in email to work around—especially if you’re in enterprise or education. Lot’s of outdated and random clients floating around out there.

    Adam – Email on Acid has a great blog post on this issue. Check it out.

    David – Anna is the best! Definitely my Sensei, as well. I would absolutely recommend her RED video to anyone interested in responsive email design. And you’re absolutely correct that what we typically report on is not the case for everyone. Every industry, business, and list is different. The most important job for any email designer is knowing your audience and tailoring your content and design accordingly.

  21. Several years ago I used to work as an email analyst for a giant news publisher in the US. We sent 100’s of millions of emails monthly. 90% of the emails were simple tables with a giant image pasted into the row/cell. We knew it wasn’t right and I would hand code + split images as much as possible. But with the sheer volume, silos of operation at the company and bureaucracy there was very, very little you could do.

    I still wonder what kind of improvements on their metrics they’d would have seen by following better standards like these. Great article, look forward to reading more-

    Thoughts In Action

  22. It’s amazing that media-queries don’t work on a modern client like Gmail desktop and android. Last week I’ve to build a simple show/hide block media query for a newsletter and I couldn’t make it work on Gmail (and outlook of course), in the rest work perfect… so I can’t understand how it’s google don’t fix this…

  23. We gave more stress on content of email when sent to existing and futuristic clients but never thought that email formatting plays vital role in it. After reading your detailed research on email format we are going to change our email campaign strategy. Thanks Jason.

  24. Maybe I’m alone in this, but I have never found the process of developing html emails any more miserable or exciting as developing websites. Once you learn the differences between the clients and what you can and can’t do, it’s really not a problem. I’ve been doing this for a while, and my experience is that things are always changing and that you are always “hacking” whether you are dealing with different email clients, different browsers and browser versions or different devices, resolutions, download speeds, etc. There is always a problem that you need to deal with in the process. If there is no “standards” way to deal with this problem then you fix it another way. Some people call this a “hack,” I just call it a solution. The problem with standards is that you are led to believe that there is a perfect way of doing something and that the environment just needs to change so that you can perform this work of art in a perfect way. It’s never going to happen.

  25. Great article Jason! I wasn’t aware that you could style alt text, which is kind of nice. Also, the bullet proof email button generator looks like pure awesomeness! Also, what’s always been surprising to me about Gmail is how far behind they are in supporting CSS compared to other email clients. They get so much praise and have so many users, yet their CSS support is much lower than Outlook and Yahoo. Go figure.

  26. Rich – Gmail is absolutely a mixed bag. On the one hand, they do some amazing things on behalf of users (tabbed inbox, enabling images by default, etc.). On the other, some of their features tend to frustrate email designers (shoddy CSS support, image caching leaving artifacts). There are a number of threads in the Litmus Community with people solving a lot of these problems. Here’s a search that may help you out if you’re running into specific issues:✓&search=gmail

  27. CampaignMonitor has a great template generator for responsive emails. I already used it to design responsive mails for the use “outside” (within other newsletter systems) but also for mails within CampaignMonitor. It’s a good point to start and learn from.

  28. Alexander – Campaign Monitor’s generator is fantastic, as are all of their tools and resources. Another resource you may want to check out is MailChimp’s Email Blueprints. There are a variety of fixed-width and responsive templates, as well as modular templates that are a phenomenal resource for learning about building good email templates.

  29. Thanks for a great article Jason, and for sharing salted. I am curious what your process is for inlining your CSS. In the salted repository on GitHub, all CSS except the media queries is already inline, and I’m wondering if you are actually inlining “by hand”, so to speak, or if you’re using an inline tool such as the Mailchimp tool or the Premailer tool. In other words, is the html file in the salted repository the actual file you develop with, or is that outputted from another tool?

  30. Doug – Glad you enjoyed the article and template! I typically take the approach of writing my styles by hand, inline as the email is developed. I know a lot of people love inlining tools, but I would much rather see that information in situ while I’m designing so that I know exactly what’s going on. This is just my preferred method, so the Salted template reflects that. It takes the same approach that we use for our emails at Litmus, everything done by hand. The styles in the head are typically resets and media query-specific styles which don’t need inlining.

  31. I’m new to media queries. I’m trying to do a $25 jobbie for a client’s email newsletter. Right now what’s working is:

    img src=”images/imagename.jpg” style=”width:100%; max-width: 500px”

    Afraid that that coding might not be good for emails, I came here. I don’t think copying and pasting this into the <style> area in the head is complete, is it?
    img[class=”img-max”] {
    width:100% !important;
    height: auto !important;

    I tried @media img……etc.etc.
    I tried taking out the brackets and making them parentheses.

    Could you post the Exact coding for the head? I must be missing something here.

    This is what I have copied exactly from your blog:

    <style type=”text/css”>

    @media screen and (max-width:500px) {
    table[class=“wrapper”] {
    width:100% !important;
    @media screen and (max-width:500px) {
    body, table, td, a, p {
    font-size:16px !important;
    table[id=“responsive-table”] {
    width:100% !important;
    @media img[class=”img-max”] {
    width:100% !important;
    height: auto !important;


  32. Good article, thank you for encouraging and enlightning the subject.

    Here is an interesting result using gif for now(svg animation are still a little complicated), that model should be subject to serious optimisation, playing on some awckward hacks, and not completely cross email clients.

    Responsive newsletter

    Have fun ! thank you

  33. Great article, learned some new things.

    Only thing that I would point out is there are problems applying bgcolor to the table-cell level. I code emails where there are alternating rows where in each row there are up to three sibling tables each with their own nested tables. (this is done for complicated layouts with aligned tables, but I’ll save the details for brevity unless someone is curious why everything is in tables instead of table-cells)

    Some email clients (looking at you, iPad, but can’t remember the others off the top of my head) will render a 1px border/gap in-between rows where each row has a different background color. This gap may not show up at first, but it may show up/disappears randomly when you pinch-open/pinch-closing the email (to make the email larger/smaller).

    The solution/work around is defining the bgcolor into the

    instead of the

    cell. Admittedly, I’ve sometimes had to do a combo of both setting in the and

    – so you may have to play around to get it to work.

  34. Have you tested adding role=”presentation” to these layout tables? I’d sure like to recommend that to my clients (from an accessibility point of view).

  35. Thanks so much Jason for a really practical guide. Lots of great links as well as examples. Many Thanks:-)

    I’ve been using FreshMail’s Coding HTML Email Guide on a couple projects with a fair amount of success. Apart from the analysis of the most popular email clients and their HTML/CSS3 properties, you will also find advice regarding Responsive Email Design. It contains the recipe for a perfect newsletter, analysis of animation and video in emails, etc.

  36. Great article! If you need a deeper expertise of your HTML email we are offering a free service, where we take a look at you HTML find the problems and point you to the right direction. As an example, due to the fact the new laptops come with the default 125% DPI and also some users had enabled desktop DPI scaling because of poor eyesight, 98% emails/templates do not render well in Outlook 2007,2010 & 2013 at 125% DPI. We’ll find find all the problems with your HTML, if there are any. We are offering this service, free of charge:

  37. Thanks for sharing! It’s so important to create responsive emails because these days a lot of people check their mailbox on smartphones. I’m glad that my email marketing platform (I have GetResponse) offers a lot of beautiful and responsive email templates.

  38. Responsive and well designed emails are difficult to design and code. We just release a free AND open source email template editor. Give it a try, looking forward for feedback!

  39. Responsive and mobile friendliness are going to be increasingly important heading into 2016 and beyond. With the amount of people browsing on mobile devices, it will probably reach north of 75% of all traffic at some point. As a web consultant it’s my job to inform my clients of the best strategy, and responsive will always factor in to the decision.

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA