Email Rendering Engines 101

A staggering 3.5 million emails are sent per second worldwide—many of them painstakingly designed by marketers to inspire action from their target audience. When those emails are opened—on phones, tablets, and laptops all over the world—they must show up looking as intended on all screen types and in all operating systems.

This presents an enormous challenge for developers because a single HTML email can show up on screens in as many as 15,000 different ways, depending on how it is rendered. While much of a developer’s work is troubleshooting specific rendering issues as they arise, understanding—and optimizing for—the various ways a message will translate from behind-the-scenes code to screens can reduce complications and make the process smoother.

That translating is done by rendering engines, software responsible for drawing text and images on a screen. The engine pulls information from a source document (usually in the form of HTML) and formats it according to various style rules, often using CSS (Cascading Style Sheets) to determine how those elements will look to an email recipient.

Email’s complicated history

Since its beginnings more than 50 years ago, email has advanced exponentially, shaped by many different influences. What started in the late 1960s as a set of technologies that allowed users to share files and messages on a central disk, evolved into a more robust and complex experience.

In the 1980s, Multipurpose Internet Mail Extension (MIME) allowed multimedia attachments to messages. Then in the mid-1990s came the rise of webmail clients—applications used to send, receive, access, and manage emails. As more people used email to communicate and as the ability to send emails with complex text and images improved, a multitude of email clients—each with their own rendering engines—were established.

Today developers routinely code for dozens of rendering engines, including Apple Mail’s WebKit, Outlook’s Microsoft Word and Internet Explorer, Mozilla Firefox’s Gecko, and Chrome’s Blink.

Each email client renders an HTML message differently, and individual users access their emails on computers and mobile devices with varying screen sizes and aspect ratios. Developers want to ensure an email’s design shows up looking consistent in everyone’s inbox, no matter the device they use to access it. But the wide array of potential viewing devices creates an ongoing set of challenges for developers to overcome.

Rendering engines serve an important purpose

Rendering engines hold the components responsible for displaying HTML email. They are the intermediary between lines of code and a viewable email.

Rendering tests allow marketers to determine if changes or adjustments need to be made to ensure emails show up as intended in the recipients’ inboxes. Identifying design issues that couldn’t have been predicted without rendering tests allows marketers to fix problems before emails are distributed.

Browsers and operating systems are always changing, usually without notice. In addition, email clients regularly make changes to their rules for their rendering engines that affect the code of an email.

For example, “©” is rendered as a copyright symbol in most email clients. During a routine review, we discovered that code was no longer rendering properly on Samsung devices. We needed to update it to an HTML Unicode character (“&#169”) for that client. Rendering tests allow us to identify and address that kind of problem before an email is released.

Best practices ease the process

While much of a developer’s job is troubleshooting specific issues like the copyright symbol snafu, a few simple steps can minimize rendering problems before they occur.

1. Use HTML tables. Tables will allow an email to render across multiple clients with fewer issues.

2. Default to web-safe fonts like Arial, Times New Roman, and Trebuchet MS when possible. If the email design includes a custom font, select a serif or sans serif backup font to use if issues come up in rendering.

3. Create absolute file paths for all images. Email is a stand-alone HTML document that isn’t hosted on the web, so file paths with spaces can be problematic for some email clients. Consider changing the file path “imagefilepath myimage.jpg” to “imagefilepath_myimage.jpg”; that underscore allows a complete connection between the images and the server it’s hosted on.

4. Freeze the first frame of animated GIFs to provide a fallback option for clients that don’t support their functionality.

5. Use inline CSS to apply style attributes—e.g., fonts, padding, and line heights and widths—directly to individual HTML elements. That’s more reliable than internal CSS, which places style commands at the beginning of a larger document.

Navigating the multitude of email clients and their different rendering engines can seem overwhelming. However, understanding how rendering engines function, and adopting some simple best practices can go a long way toward ensuring your emails show up as intended across platforms, devices, and screen sizes.

Ed Ball is a front end developer at The Lacek Group, a Minneapolis-based data-driven loyalty, experience, and customer engagement agency that has been delivering personalization at scale for its world-class clients for more than 30 years. The Lacek Group is an Ogilvy company.