Your pre-send checklist for HTML email rendering
· 5 min read
Test HTML email rendering properly: why Outlook differs, a six-step pre-send checklist, client-by-client constraints, defensive coding, and seed-list workflow.
- Email clients render HTML with wildly different engines; Outlook uses desktop Word logic
- Table layouts and inline CSS remain the compatibility baseline for campaigns
- Test across Gmail, Outlook, and Apple Mail at minimum before any large send
- Our browser-based template tester checks structure before you spend sends on seed lists
Why email is not the web
Anyone who has tried to test HTML email rendering knows the gap: a web page renders in whatever engine the visitor chose; an HTML email renders in engines nobody would choose. The history of HTML email explains how this happened: Microsoft wired Outlook's editor to the Word rendering engine for security reasons, producing layout behavior unlike any browser. Gmail historically stripped embedded styles entirely. The support matrices still track both today. The result is a format where modern CSS works on your phone and silently vanishes in a client your CFO uses.
The practical consequence: email development resembles the web of two decades ago. Support matrices, not specifications, define what you can use, and community resources like the CSS support guide from Campaign Monitor catalog which properties survive which clients.
Test HTML email rendering: a pre-send checklist
- Structure first: build with nested tables and inline styles, checking support per property via per-property pages rather than trusting habit
- Static rendering check: paste the template into our email template tester to catch broken tags, unclosed tables, and unsupported patterns before sending anything; our HTML live preview renders the same markup instantly in a browser frame
- Seed list send: deliver to real inboxes across Gmail web, Apple Mail, and an Outlook desktop if available
- Dark mode pass: verify colors survive forced inversion on mobile clients
- Plain-text fallback: confirm the multipart alternative reads sensibly when images are blocked
- Link and image audit: every URL resolves, images use absolute HTTPS sources
The clients that actually matter
| Client family | Engine | Known constraints |
|---|---|---|
| Gmail (web, apps) | Sanitized proprietary | No embedded style blocks historically; aggressive attribute stripping |
| Outlook Windows | Microsoft Word | No background images, partial CSS2-era support, odd padding math |
| Apple Mail, iOS | WebKit | Mostly modern; dark mode inversions surprise |
| Webmail others | Varies | Proxy rewrites of links and images are common |
Client mix shifts yearly; Litmus's market-share tracker keeps the proportions current. Support details shift between releases, so consult the live can-I-email support matrix when reaching beyond the safe baseline rather than memorizing folklore that ages badly.
Defensive coding patterns that survive everywhere
- Inline every style; assume no head styles will load
- Lay out with table cells and fixed widths for Outlook, enhanced by fluid techniques elsewhere
- Provide background colors behind every background image so text stays readable when images block
- Use web-safe font stacks with graceful fallbacks rather than custom fonts alone
- Keep total width near 600 pixels, the de facto ceiling most clients render comfortably
These patterns read as retro, and they are; they exist because email's rendering fragmentation never resolved the way browser wars did. Defensive structure costs little once templated and buys predictable rendering, the same isolation logic our live preview guide applies to testing markup safely. Gmail's own design documentation confirms the supported subset.
Bulletproof buttons and Outlook conditionals
Buttons break worst across clients because padding, border-radius, and background-color support varies. The classic fix wraps real anchor text in a table cell with a hardcoded background color, plus a VML fallback for Outlook Windows behind conditional comments:
<!--[if mso]>
<v:roundrect xmlns:v="urn:schemas-microsoft-com:vml" href="https://example.com">
<center>Confirm order</center>
</v:roundrect>
<![endif]-->
<!--[if !mso]><!-- -->
<a href="https://example.com" style="background:#2563eb;color:#fff;display:inline-block;padding:12px 24px;border-radius:4px;text-decoration:none;font-family:Arial,sans-serif;">Confirm order</a>
<!--<![endif]-->Conditional comments come from Microsoft's own documentation, and the table-button pattern is catalogued at buttons.cm. Background images follow the same logic: declare a fallback color behind every image so blocked graphics never leave unreadable text.
A sustainable testing workflow
- Draft the template defensively using the patterns above
- Run structural validation through the template tester, fixing what it flags
- Hand-build the HTML from the design file, then generate a PDF proof of the finished template for stakeholder sign-off
- Send the seed list; screenshot each client's result into a shared doc
- Only after all three major families pass, schedule the full send
- Log which fixes each campaign needed; the list becomes your team's playbook
Screenshots deserve emphasis: written descriptions of rendering bugs mislead, while side-by-side captures settle debates instantly and build institutional memory of client quirks. Run one campaign through both Gmail and a real Windows Outlook install before your first send; those two renders alone teach more than any support table ever will.
Assume nothing, test three ways
Testing HTML email rendering comes down to respecting the format's fragmentation: code defensively against the documented baseline, validate structure mechanically before spending sends, and verify visually in the three client families where your audience actually reads. The checklist above turns a source of pre-send anxiety into a repeatable routine that ships campaigns confidently.
Written by
Callum Reid
Markdown is a family of closely related dialects, and most bugs in it come from writing for one and rendering in another. On top of that sit tables, footnotes, task lists, strikethrough, attributes, maths and raw HTML. A renderer either enables a subset of these or ignores them silently, and ignored syntax usually surfaces as literal punctuation.
Fenced code blocks are the most reliable part and still have edge cases. Info strings carry a language identifier for highlighting, and some renderers read options from the same string. An unclosed fence swallows the remainder of the document, which is why a stray backtick is worth checking first when a page renders short.
Links get their own treatment. Reference-style links resolve anywhere in the document, which is convenient right up until two definitions collide. Bare URLs are autolinked by some renderers and left as plain text by others, and a link with mismatched brackets produces output that looks fine and points at the wrong place. Raw HTML is where sanitisation earns its place.
Markdown passes HTML through by design, so a document containing a script tag or an event handler attribute reaches the browser unless the pipeline strips it. Sanitisers differ in which tags they allow, and allowing a tag for a benign reason can permit an attribute with a script handler, reintroducing the problem it was meant to remove. I cover heading level discipline too, because renderers frequently promote or demote headings to fit a template, and that silently breaks both the outline and accessibility.