The Code Review Process for HTML Emails [Free Checklist]
“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.
Table of content
-
01
What to check during the email code review process - Get your email code review checklist
- 1. The basics checks
- 2. Is the email code optimized for mobile?
- 3. How clean is your email code?
- 4. Do you have fallbacks in place?
- 5. Did you check the email code for accessibility?
- 6. Is the email code optimized for dark mode?
-
02
Tools to streamline email code review - Get your email code review checklist
What to check during the email code review process
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.
Get your email code review checklist
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:
1. The basics checks
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.
Email header code snippet
<!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:
- Making sure the email is the correct width (no more than 700px max)
- The code doesn’t refer to an external CSS style sheet
- There’s no unsupported elements, like javascript or iframes
- Styles conform to email code standards, such as using 6-digit vs. 3-digit hex codes for colors
- Images are optimized for high resolutions displays
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.
2. Is the email code optimized for mobile?
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:
- Set media queries for min max width to target screen sizes
- Button height of at least 44px
- Right font size for readability
- Columns and stacking work correctly
Code snippet for a min-max width query:
@media only screen and (min-width: 400px) and (max-width: 600px) {...}
3. How clean is your email code?
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.
4. Do you have fallbacks in place?
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.
Example code snippet for a font stack
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:
- Animations or other dynamic content: While most clients today support GIFs, it’s still important to make sure any animations you’re working with have a still image that you can show instead.
- Personalization fallbacks: No one wants to receive, ‘Hey, $%firstname%$’! Make sure you have copy in place in case there isn’t a first name on file, or whatever kind of personalization you’re working with.
- Plain text version or a “View in browser” link: I’m still surprised how few brands send a plain text version alongside their HTML one. I always include a “view in browser” link to make sure emails are accessible and it’s a last-chance fallback just in case something goes weird with the HTML.
For some help with interactivity and dynamic content, check out some of the interactive email fallback strategies we recommend here on our blog.
5. Did you check the email code for accessibility?
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:
- Alt text on all images
- Table roles set correctly (role=”presentation”) so screen readers process your code correctly when they read them
- Using semantic code, especially <h> tags for headings and <p> tags for paragraphs, so screen readers can differentiate between them
- That dark mode is working correctly in all email clients and not washing out the styles (we’ll talk more about this in a minute)
Code snippet for setting table roles
<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.
6. Is the email code optimized for dark mode?
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:
- Using transparent PNGs
- Using media queries for dark mode @media (prefers-color-scheme)
- Targeting Outlook.com dark mode specifically [data-ogsc]
Get some dark mode email code snippets to help you develop campaigns for darker settings.
Tools to streamline email code review
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.
Get your email code review checklist
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.
