A critical step in creating HTML is making sure what you’ve designed and coded shows up in your subscribers’ inboxes. Even if your HTML email displays like you want in your own email program, some recipients aren’t able to view HTML email in their email programs.

In addition to your HTML, you should send a plain-text alternative version of your message for those people who can’t view HTML emails. When a recipient receives your email, their email program will automatically determine which format to display.

Multipart/Alternative MIME format sends both the HTML and plain-text versions of an email. MailChimp automatically creates a plain-text version of a campaign, and also works alongside internet service providers (ISPs) and anti-spam groups to ensure the best delivery possible.

Fundamental Principles

HTML Vs. Images

Generally, email buttons are done in two ways. They’re either built with HTML, or designed as images. Both methods have pros and cons, but we prefer (and urge you to prefer) HTML buttons. HTML buttons aren’t dependent on your email recipient having images enabled in their email client, which means that your call to action is always obvious. HTML buttons will load faster and they don’t vanish if an image server goes down. Those are the upsides. The downsides are more design-related: image-based buttons allow you to get more fancy, so you can achieve a much greater range of visual styles with an image-based button:

Anything Photoshop can do can be brought to bear on your button; drop shadows always work, letting you avoid having to deal with CSS3 drop shadows. It’s the same with gradients or rounded corners or typeface. But, again, because the buttons are image-based, they’re subject to the image-blocking that every email client does by default. As email goes increasingly mobile, keep in mind that images tend to slow things down when an email loads; HTML doesn’t

Tables within Tables

For finer control of your HTML, try nesting

elements when building emails. At its simplest, an email should be at least two tables deep. There’s a good reason; you must provide a table to serve as a redundantelement, as some email clients strip out the element when they render the email.

Responsive Mobile-Friendly Email Attributes

The internet’s been in “mobile everything” mode for a couple of years now, but as far as email is concerned, the idea is a little younger. Despite the fact that emails are still coded using the outdated table standard, it’s possible to create modern, mobile-friendly, responsive emails using the same principles we see applied to traditional websites. There’s a distinction to be made between “mobile-friendly” and “responsive,” however, since a mobile-friendly email is not necessarily responsive, and a responsive email is—generally speaking—always mobile-friendly.

Can be fixed-width but still mobile-optimized. An email with a fixed width of 320px (the width of a phone screen in portrait orientation) is one example. Font sizes don’t change dependent on screen size, but are large enough to be readable on small screens. Can retain a multi-column layout while allowing for readers to tap and zoom into each individual block of content, for easier reading. Use large, thumb-trappable buttons for calls to action.

Use media queries to adjust email width dependent on the size of the display on which its viewed. That way, the email’s width adapts to any display size in any orientation. Font sizes change from desktop to mobile displays. Several different display sizes can be targeted using different media queries Layout can be changed from multi-column to single-column on the fly. Different elements (image-based buttons, for example) can be hidden and shown dependent on which platform the email is viewed on.

Best Design Practices

When designing mobile email, we try to follow the mantra “one eyeball, one thumb, and arm’s-length.” This means that, on a small screen, an email should be easily readable with one eye (The other one is presumably paying attention to traffic—don’t do this!), any links and calls-to-action usable with one thumb, and any text or visual cues large enough so that all of the above can be done comfortably at arm’s length.

Guidelines for achieving these objectives: * Minimum font size of 16px—Apple recommends 17-22px, Google recommends 18-22px. (We’ve found 16px Georgia to be nice and readable.) * Call-to-action touch targets, such as buttons, should be at least 46px squared (Apple recommends 44px squared, Google recommends 48px squared—we’re splitting the difference). * Avoid clustering several links together in your copy. It makes individual links very difficult to access.

These guidelines should get you started on crafting effective mobile emails, but if you need deeper insight, MailChimp’s done some leg work on the subject and compiled it into a guide filled with insights.

Device Size Matters

Consider how people use their devices. Human behavior should definitely influence your designs; whether someone is viewing an email on a phone or tablet can lead to very different design choices. Start with how people hold their devices.

Phones are generally held in one hand and used with one thumb. The areas where it’s most comfortable to tap with the thumb are opposite of the user’s dominant hand (right-handed taps comfortably on left side of the screen):

Tablets, on the other hand (Ha!), are generally held in two hands, allowing thumbs to reach touch targets on the sides on the screen, but not the middle:

Where possible, your designs should accommodate both scenarios. Consider having important calls-to-action like buttons span the full width of the email when its viewed on a mobile device. By doing so, you’re covering both right- and left-handed readers.

You can also go the extra step of providing multiple ‘break points’ for your design with media queries that target phones in landscape and portrait orientations, and provides similar solutions for tablets. At the very least, design an email that can scale down to a 480px width – the most common width of a phone in landscape orientation.

Single-Column Vs. Multi-Column

The type and amount of content you plan to send can dictate your email’s layout. Emails break down into two general layout types: single- and multi-column. Here are some pointers to help you decide which is best for your email.

Single-Column

  • Best for focused, succinct messages
  • Tend to be easier to read than multi-column emails
  • Best for emails requiring a call to action

Multi-Column

  • Best for emails with wide variety of content
  • Work well for product-based/e-commerce emails
  • Best for emails which include non-crucial content best featured in a sidebar

These layouts can be used in a variety of ways to create interesting, effective email. There are plenty of great-looking examples in the Inspiration Gallery that you can use as a jumping-off point for your ideas.

Post images on a publicly accessible web server.

Use absolute paths in your code when you embed images or link to files. Make sure your assets are hosted on a publicly accessible server, so your recipients can see the images or download the files. Avoid free hosting sites, too, because these often have bandwidth limits that may prevent your images from displaying.

Use tables and shim.gifs.

Keep the code simple. All email programs use different methods to render HTML, like Internet Explorer, Microsoft Word, or their own proprietary renderer, so more high-level coding may not display as intended.

Set email width to 600px or less.

Most people view messages in their preview panes, which are narrow and small. The templates we design at MailChimp are never more than 600 pixels wide, or they’re fluid-width.

Test how it renders.

Because all email programs render HTML differently, test your HTML email on different email programs. You can also use the MailChimp Inbox Inspector to test how your email renders in major programs.

Webmail services strip certain elements.

Browser-based email services like Gmail, Yahoo, and Hotmail strip out your DOCTYPE, BODY, and HEAD tags, so your code doesn’t override theirs. Anything you’d normally code inside those tags (background colors, embedded CSS, JavaScript, background music files, etc.) will be removed. Use inline CSS and FONT tags. MailChimp offers a CSS inliner tool to help with this.

Think like a spam filter.

Consider spam filters and spam firewalls when you code.

Fonts

Unfortunately, you can’t just go and use an excellent font like Gotham for your copy. Like anything else with HTML email, there are some limitations. Here, you’re pretty much stuck with the basic, cross-platform fonts:

These are your best bets for sans serif fonts

  • Arial
  • Arial Black
  • Tahoma
  • Trebuchet MS
  • Verdana

These are your best bets for serif fonts.

  • Courier
  • Courier New
  • Georgia
  • Times
  • Times New Roman

It’s best to stick with a small list of fonts known to work across all platforms, and your ideal, bullet-proof font stacks should look something like this.

  • sans-serif: Helvetica, Arial, Verdana, Trebuchet MS
  • serif: Georgia, Times New Roman, Courier

Here’s a list of all widely-supported cross-platform fonts: Helvetica, Arial, Arial Black, Comic Sans, Courier New, Georgia, Impact, Charcoal, Lucida Console, Lucida Sans Unicode, Lucida Grande, Palatino Linotype, Book Antiqua, Palatino, Tahoma, Geneva, Times, Times New Roman, Trebuchet MS, Verdana, Monaco.