KoltrixTransactional HTML that renders everywhere: the constraints
Email clients support a narrow, quirky slice of HTML and CSS. The constraints that matter for receipts and alerts, and a structure that survives them.
On this page(12 sections)
- The landscape you are rendering into
- Constraint 1: layout with tables, not flexbox or grid
- Constraint 2: inline your critical styles
- Constraint 3: keep it single-column and simple
- Constraint 4: buttons that work everywhere
- Constraint 5: images are optional
- Constraint 6: dark mode will repaint you
- Constraint 7: size and clipping
- Constraint 8: fonts and text
- A pre-send checklist
- Testing without losing a week
- Bottom line
Email HTML is not web HTML with a few quirks. It is a separate, older dialect, rendered by dozens of clients that each strip, rewrite or ignore different parts of your markup.
For transactional mail, where clarity matters more than flair, the winning strategy is to design for the constraints from the start.
The landscape you are rendering into
Your receipt or alert will be opened in some mix of:
- Webmail (Gmail, Outlook.com, Yahoo and others), which sanitizes your HTML and embeds it inside its own page, so your CSS competes with theirs.
- Desktop Outlook for Windows, which for many versions has used Microsoft Word's rendering engine for email. Word supports a limited subset of CSS and has its own layout behavior.
- Apple Mail and iOS Mail, which use WebKit and support far more of modern CSS.
- Android mail apps, which vary.
- Text-only and accessibility tools, which may use your plain-text part or read the HTML with a screen reader.
Support changes over time, and no single article can track it. Sites that maintain per-client support tables for CSS and HTML features are worth bookmarking. What follows are the durable constraints that have held for years.
Constraint 1: layout with tables, not flexbox or grid
Flexbox and CSS grid are unreliable across email clients, and Word-based Outlook ignores them entirely. The dependable layout primitive is still the HTML table.
<table role="presentation" width="100%" cellpadding="0" cellspacing="0" border="0">
<tr>
<td align="center">
<table role="presentation" width="600" cellpadding="0" cellspacing="0" border="0" style="max-width:600px;width:100%;">
<tr>
<td style="padding:24px;font-family:Arial,sans-serif;font-size:16px;line-height:24px;color:#1f2937;">
Your order A-10293 has shipped.
</td>
</tr>
</table>
</td>
</tr>
</table>role="presentation" tells screen readers the table is for layout, not data. A centered container about 600 pixels wide remains a sensible default for readability on desktop while scaling down on phones.
Constraint 2: inline your critical styles
Many clients support <style> blocks in the head now, but not all, and some strip them in certain contexts, such as forwarded messages. Put the styles that matter for readability inline on elements: font, size, color, padding, background. Use a build step that inlines CSS automatically so you can still author with classes.
Keep a head <style> block for progressive enhancements such as media queries and dark mode adjustments, accepting that some clients will ignore them.
Constraint 3: keep it single-column and simple
Transactional email is read quickly, often on a phone, often in a notification preview. A single column with clear hierarchy beats a multi-column layout that collapses unpredictably:
- A short heading stating what happened.
- The key facts: amount, order number, date, the code.
- One primary action.
- Supporting details.
- A footer with your address and how to get help.
Multi-column layouts multiply the number of rendering combinations you need to test.
Constraint 4: buttons that work everywhere
A CSS-styled link is the most reliable button. Use a table cell with a background color and a padded link inside:
<table role="presentation" cellpadding="0" cellspacing="0" border="0">
<tr>
<td style="background:#2563eb;border-radius:6px;">
<a href="https://example.com/reset?token=abc" style="display:inline-block;padding:12px 20px;font-family:Arial,sans-serif;font-size:16px;color:#ffffff;text-decoration:none;">Reset your password</a>
</td>
</tr>
</table>Word-based Outlook may ignore border radius and some padding, so the button looks squarer there but still works. Never make an image the only clickable element: images are often blocked by default.
Constraint 5: images are optional
Assume images will be blocked for some recipients and fail to load for others. That means:
- No critical information exclusively in images. Order totals, codes and instructions must be live text.
- Always set
alttext,widthandheightso blocked images do not collapse your layout. - Host images on HTTPS on a domain you control.
- Skip background images for anything important; support is inconsistent.
Constraint 6: dark mode will repaint you
Several clients apply dark mode by inverting or adjusting your colors, sometimes partially. You cannot fully control the result, but you can reduce damage:
- Avoid pure black text on pure white backgrounds hard-coded into images.
- Use transparent PNG logos with a subtle outline or provide a version that works on dark backgrounds.
- Add a
prefers-color-schememedia query for clients that respect it, and test in clients that force their own palette.
Constraint 7: size and clipping
Gmail clips messages whose HTML exceeds roughly 102 KB, showing a "View entire message" link. For transactional mail that is a real problem: the clipped part may contain the action or the footer with an unsubscribe link. Keep markup lean, avoid giant inlined style duplication, and minify the output.
Constraint 8: fonts and text
Web fonts work in some clients and silently fall back in others. Always specify a full fallback stack, and make sure the fallback looks acceptable. Use a font size of at least 14 to 16 pixels for body text and a generous line height. Set lang and dir on the root element so screen readers pronounce text correctly.
A pre-send checklist
| Check | Why |
|---|---|
| Layout built with tables, max width around 600px | Survives Word-based Outlook |
| Critical styles inlined | Survives clients that strip style blocks |
| Key facts in live text, not images | Survives image blocking |
| Every image has alt, width, height | Layout holds when images are off |
| Button is a padded link in a table cell | Works without images or advanced CSS |
| HTML well under 100 KB | Avoids Gmail clipping |
| Plain-text part present and readable | Accessibility and fallback |
| Tested in at least Gmail web, Outlook desktop, Apple Mail and one Android client | Covers the main engines |
Testing without losing a week
You do not need to test every client for every change. Maintain a small set of core templates built from a shared, well-tested layout. Test the layout thoroughly across clients once, then for each template test only the content. Screenshot testing services can render messages across many clients at once if your volume justifies it. For everything else, send to a handful of real accounts.
Bottom line
Transactional HTML succeeds when it is boring on purpose: table layout, inline styles, a single column, live text for every important fact, bulletproof buttons and lean markup. Build one robust layout, test it hard, and let every template inherit it.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
