Email Development
The Code Review Process for HTML Emails [Free Checklist]
![Image for The Code Review Process for HTML Emails [Free Checklist]](https://www.emailonacid.com/wp-content/uploads/2022/02/HowtoConductanEmailCodeAudit_Blog.png)
Email Development
“Have you checked it in Outlook?”
It’s like the phrase “have you turned it on again/off again” for email devs. No matter how many times you check images, alt text, responsiveness, and fallbacks…something gets funky in one email client or another.
Unlike web development, HTML email development exists at the whims of finicky email clients. Inconsistent support (or random bugs introduced by software updates — trust me, I’ve been there) can derail templates and one-off campaigns.
That’s why it’s so important to have a defined email code review process. With so many moving pieces for a given email campaign, you want to have peace of mind that you’re dotting your i’s and crossing your t’s, metaphorically speaking.
We put together this comprehensive checklist we use for every single campaign Sinch Email on Acid sends. Read on or you can download a free digital or printable version for your desk.
Short answer: Everything.
It doesn’t matter how many times you’ve used the template before, or how many emails you’ve sent. Test everything, every time, especially when it comes to code development. Regardless of the message, design, or styles, it’s up to you to make sure your emails are readable no matter where your audience is opening them.
These checks are also smart to follow if you’re conducting an email marketing audit that includes an email code review.
Want to refer back to this list? We’ve got you. Grab an interactive PDF of our email code review checklist to make sure you’ve covered all your bases before launching the next campaign.
Here’s what you should always check during the email code review process:
First, do a quick rundown of the basics. Start at the top, naturally, with the header code, to make sure you’ve got the right DOCTYPE, language settings, as well as meta tags set for responsiveness, dark mode, and the correct character set. This code rarely changes from email to email, but you never know if there’s a weird copy/paste thing going on.
<!DOCTYPE html>
<html lang="en" dir="ltr" xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width,initial-scale=1 user-scalable=yes">
<meta name="format-detection" content="telephone=no, date=no, address=no, email=no, url=no">
<meta name="x-apple-disable-message-reformatting">
<meta name="color-scheme" content="light dark">
<meta name="supported-color-schemes" content="light dark">
<title>Email title</title>
<!--[if mso]>
<noscript>
<xml>
<o:OfficeDocumentSettings>
<o:PixelsPerInch>96</o:PixelsPerInch>
</o:OfficeDocumentSettings>
</xml>
</noscript>
<![endif]-->
<style>
:root {
color-scheme: light dark;
supported-color-schemes: light dark;
}
</style>
</head>
Find a detailed explanation of the email header over at GoodEmailCode.com.
Since the header code controls the rest of the email, it’s critical to make sure everything is correct there first. That also includes:
This is also where you can make sure you’ve coded your tables and ghost tables correctly in Outlook. And don’t forget to check other common Outlook rendering issues like unwanted white lines, background images, and alignment issues when using columns.
It’s the classic 80/20 rule at play here: You’ll likely spend 80% of your time looking at only 20% of your clients, and Outlook is the most problematic client you’ll run into…but you have to work with it, because it’s still the third most popular email client out there.
On average, Americans check their phones 344 times per day. With over 6 billion mobile users on the planet, the second most important check you can make is to confirm your email renders correctly not just on desktop clients, but on mobile ones, too.
Whether you’re using mobile-friendly, responsive, or fluid hybrid email design, you’ll want to check:
@media only screen and (min-width: 400px) and (max-width: 600px) {...}
When you’re building on older emails or re-using templates, email code can get messy really quickly. That’s because you often have to create workarounds or hacks for specific email clients or functionality.
But it’s important to make sure you’re streamlining your email code as much as possible. Unnecessary code weighs down your emails and increases the size, making them slower to load. Clients like Gmail clip emails at 102 kb, so keep that in mind.
You’ll want to clean up spacing, padding, and your tables to make sure everything works properly, too. There are a few tools out there that can help you consolidate your code to decrease the file size. I use Email Comb or Parcel to remove unused CSS.
Get some advice from Parcel founder, Avi Goldman, on how to prevent Gmail clipping.
Today’s emails are more personalized and customized than ever before, and that means headaches for email devs. Fallbacks act as placeholders when data isn’t available or supported. For example, there are font fallbacks (aka font stacks) if you’re using a custom font that an email client doesn’t support.
A sans-serif inline style font-stack could look like this:
style="font-family: Helvetica, Arial, sans-serif;"
You want to double-check that you have fallbacks in place so even if something isn’t supported, your audience can still engage with your email:
For some help with interactivity and dynamic content, check out some of the interactive email fallback strategies we recommend here on our blog.
If your audience can’t read or interact with your emails…then why do all that work? That’s at the core of email accessibility: making sure every member of your audience can actually receive the contents of your message. This means checking for:
<table width="100%" border="0" cellpadding="0" cellspacing="0" style="width: 100%;" role="presentation">
Using role=”presentation” ensures screen readers interpret the email as body copy and not data in the table.
For more on all this, including how to use ARIA and code semantic HTML emails, check our coding accessible emails.
Dark mode is one of the newest additions to this checklist, and one of the most challenging. It’s become quite popular — 44% of email marketers are considering the darker UX and another 28% plan to start making it part of the email production process soon.
The thing about dark mode is, if it works, it looks great. But if it doesn’t, your email is pretty much unreadable. Some clients flip the colors and others don’t show anything at all. You want to make sure you’ve coded dark mode correctly in the header code of your email and optimized text and background color.
To make sure your emails work in dark mode, check that you’re:
Get some dark mode email code snippets to help you develop campaigns for darker settings.
A great resource to check out if you’re not sure whether a client supports a coding technique is supported or not is Can I Email. And I’ve already mentioned Parcel, which is an excellent tool for coding emails since it was built by an email developer for email developers.
The automated email checklist from Sinch Email on Acid is another helpful tool, especially for double-checking and finalizing email code before you hit send.
While the email code review process seems like a lot, at this point, I rarely even think twice about these checks. That’s partially because they’re built into the email development process for every email we send, and partially because Email on Acid takes care of several key checks automatically.
Since you can preview your work as many times as needed with Email on Acid, you can tinker with your code until you’re 100% satisfied. That’s the beauty of our unlimited email testing.
