Email Client Rendering
Date: 2026-08-17
The other runtime, and a far less forgiving one. Table layouts, inline CSS, no JavaScript, unpredictable dark-mode inversion, and rendering engines that range from a modern browser to a word processor. Everything you know about the web applies here only after checking.
Email client rendering is how mail clients — webmail, desktop and mobile apps — parse and display the HTML of an email, each with its own engine, sanitiser and support table.
Why it’s this way
BROWSER EMAIL CLIENT
one rendering engine per browser dozens: WebKit, Blink, Gecko,
and Microsoft Word's engine
for desktop Outlook on Windows
you control the document the client wraps, rewrites and
strips your document
CSS cascade works <style> blocks stripped by some
clients — The CSSOM
JavaScript runs never. stripped everywhere,
for good reason
you can iterate and deploy **an email cannot be recalled**
The cascade row is the significant one: without a reliable CSSOM, every style has to be inlined onto the element itself.
The last line changes the engineering posture entirely. There is no hotfix. A broken email is broken in every inbox it reached, permanently — which is why the testing discipline here is stricter than for the web.
The rules that still hold
- Tables for layout. Not nostalgia —
floatandflexare unreliable, and Outlook’s Word-based engine handles neither. Nested tables with fixed widths remain the only universally safe structure - Inline every style.
<style>blocks are stripped by some clients, notably several webmail interfaces. Author with a<style>block for readability and run an inliner in the build to push declarations onto elements - Fixed width, typically 600–640px. Not because screens are that size, but because it’s the width that survives every client’s own chrome
- No JavaScript, no forms, no
<video>. Interactivity, where it exists at all, is CSS trickery that works in a minority of clients — build it as an enhancement over a working baseline, or not at all - Web fonts fail more often than they work. Always a full fallback stack ending in a system font
- Absolute URLs everywhere, including images. There’s no document base to be relative to
Dark mode, which is the modern hard part
Three different behaviours, and you get whichever the client chooses:
1 NO CHANGE your colours render as authored
2 RESPECTS prefers-color-scheme
you supply a dark palette, it's used
← Apple Mail, some others
3 FORCED INVERSION the client rewrites your colours itself,
with its own algorithm
← several Outlook and Gmail contexts
→ dark text on a light logo becomes
light text on a light logo
→ your careful palette becomes something else
Design for inversion rather than fighting it. The practical defences:
- Transparent PNGs with a stroke or outline on logos, so they read on either background
- Avoid pure white and pure black, which invert most aggressively
- Test both modes in every client — this is now the largest single source of email rendering bugs
- Don’t rely on background colour to create contrast with text; use elements that carry their own contrast
Images and the fallback that matters
Images are blocked by default in several clients, so the email must communicate without them.
✓ live text for anything that matters — headline, offer, CTA
✓ meaningful alt text, styled so it looks intentional when shown
✓ background colours behind image areas
✗ an entire email as one image ← invisible when blocked, unreadable
on a screen reader, and a spam signal
The open-tracking pixel is an image, so blocked images mean the open goes unrecorded. Combined with privacy features that pre-fetch every image on the recipient’s behalf — inflating opens with ones that never happened — open rate is close to unusable as a metric and should not be a north star for anything — Vanity Metrics, Lifecycle Messaging.
Click rate survives, because a click is a real navigation to a URL you control — so build measurement on clicks and downstream conversion, with UTM parameters on every link — UTM Governance.
Accessibility
Often worse in email than on the web, and the fixes are cheap:
role="presentation"on layout tables, or a screen reader announces the grid structure of your designlangon the<html>element, so pronunciation is right- Real headings, not styled
<div>s - Alt text on every image, empty (
alt="") for decorative ones - Contrast that survives both modes — Colour Contrast, Screen Readers
The workflow that prevents disasters
1 BUILD from a tested template. never from scratch
2 INLINE styles as a build step
3 RENDER-TEST across a client matrix — a service that screenshots
the email in 40+ clients, both light and dark
4 SEND A SEED LIST to real accounts on the clients that matter most
5 CHECK LINKS — every one, including the unsubscribe
6 SPAM-TEST — authentication, image-to-text ratio, subject line
7 SEND to a small percentage first where the platform allows
Step 3 is not optional and can’t be replaced by a browser preview. An email that looks perfect in a browser tells you nothing about Outlook.
Authentication is the deliverability floor — SPF, DKIM and DMARC records configured correctly on your sending domain. Without them a well-built email lands in spam and none of the above matters. [CHECK: the major mailbox providers have tightened bulk-sender authentication requirements; confirm the current thresholds and requirements before a large send.]
Where it interacts
- Lifecycle Messaging — what the emails are for, and the campaign logic around them
- Browser Compatibility — the same problem shape, with a longer tail and no ability to patch
- Progressive Enhancement — the only sane authoring stance here: a baseline that works everywhere, enhancements for clients that support them
- Klaviyo — where these templates are commonly authored and sent from