How to Code HTML Emails


One thing we stress is that in order to code your own HTML email, you really, really, really need to know how to code HTML. You should be able to code web pages "from scratch" without the help of any WYSIWYGs (like Front Page, or even DreamWeaver). If you're that good, then you really don't need to worry about a million little rules (like what CSS definitions work in this email program, but not in that email program). Just being able to understand "the fundamentals" will save you a lot of time and frustration.

Coding Your HTML Emails: Fundamental Principles

An HTML email is nothing but a web page. So if you can code your own web page, you can code your own HTML email templates. Only you've got to do it the old fashioned way. Remember back in the 90's when there were no WYSIWYGs yet, and you had to code everything by hand? Remember the Internet Explorer vs. Netscape wars? Remember how you had to test your work over and over and over again? HTML email is a lot like that. Times 10.
    1. The most important thing (if you wish to preserve your sanity) is to keep it simple. Focus on your message, not your craftiness.
    1. Images should be posted on your publicly accessible web server. In your code, use absolute paths to point to them. Attachments are often stored in randomly named temporary cache folders by some email programs. They also hog a lot of bandwidth (especially when they bounce) so attachments are not the way to go.Tip: One common mistake is to post your image files on an intranet, extranet, password-protected server, a secure server that's extremely slow, or a free hosting site (images may not show due to bandwith issues). Post images on your fast, public-accessible web server.
    1. TABLES and SHIM.GIFs are your friend. Keep it simple, because email programs use different HTML rendering engines. Some of them use Internet Explorer, Firefox, or in the case of Outlook 2007, Microsoft Word (what a headache!). Some of them use their own proprietary renderers (Lotus used to do that, which is why you'll find lots of old rants on out there about Lotus and HTML email problems).
    1. Don't code your emails too wide. Most people view messages in their preview panes, which are narrow and small. Don't ask  if you should code for 1024x768 screens or 800x600. Please. This is email we're talking about here. The preview pane in AOL 9 is less than 200 pixels wide. Think small. The most commonly used width for emails is between 500 and 600 pixels and in some cases they are responsive so they can break down into smaller sizes.
    1. Test how it renders. Your email will display differently in all the different email programs out there. So testing is a must. And we're not talking about IE, Firefox, and Safari. We're talking about Outlook, Outlook 2007, Outlook 2003, Outlook Express, Thunderbird, Apple Mail, Eudora, Lotus, Gmail, Yahoo!Mail, AOL, AOL Web, Hotmail, MSN, Comcast, Earthlink, and on and on and on. How to cope? Keep it simple. TABLES. 600 pixels wide max.
    1. Webmail services are deceptively tricky. Email services that are browser-based, like Gmail, Yahoo!Mail, Hotmail, etc., will strip out your DOCTYPE, BODY, and HEAD tags. Makes sense---they don't want your code to potentially override theirs. Anything you'd normally code inside those tags (bgcolors, embedded CSS, JavaScript, background music files, etc) will also get stripped.
    1. Think like a spam filter. You have to consider spam filters and spam firewalls when you code. It's pretty obvious that spammy words like "Viagra" or "V14GR4" will get you spam filtered. But spam filters also look for stuff like, "do you have too many images, and not enough text?" If you're sloppy with your code, you'll look like a sloppy spammer.
    1. 99% of your CSS won't work (especially not in the browser-based email services like Gmail, Yahoo!Mail, etc.). That means no CSS-positioning, DIVs, etc. Before you ask me for a detailed list of what works and what doesn't, just remember this (it'll save us all a lot of time): When your email is opened in Gmail, for example, the CSS in your HTML email could potentially override the CSS on the rest of their page. So they disable a lot of it. Inline CSS is safer, and plain-old style attributes in SPAN tags are safest. Or check out Premailer's CSS inliner tool.