HTML Email Coding Tips
Essential coding techniques for creating email templates that render consistently across email clients from Outlook to Gmail to mobile apps.
The Unique Challenge of Email HTML
HTML email coding is fundamentally different from web development. Email clients vary wildly in their rendering engines and CSS support. Outlook uses Microsoft Word's engine. Gmail strips many CSS properties. Mobile clients have their own quirks. Success requires understanding these limitations and coding defensively.
Table-Based Layout
Despite modern CSS capabilities, tables remain the most reliable way to structure email layouts. Use nested tables for complex layouts, and add role="presentation" to prevent screen readers from announcing layout tables as data tables.
Table Best Practices
- Set cellpadding="0" and cellspacing="0" explicitly
- Use border="0" to remove default table borders
- Specify width on tables, not just cells
- Nest tables for complex multi-column layouts
- Use align and valign attributes for positioning
CSS in Email
Inline Critical Styles
Many email clients strip styles from the head section. Inline your most important CSS directly on elements. Use tools to automate this process while keeping your source code maintainable.
Supported CSS Properties
Widely supported: color, background-color, font-family, font-size, font-weight, line-height, text-align, padding, border, width, height.
Limited support: margin (use padding instead), float, position, flexbox, grid, max-width (inconsistent).
Outlook-Specific Fixes
Microsoft Outlook requires special attention due to its Word-based rendering engine.
Conditional Comments
Use conditional comments to serve Outlook-specific code when needed. This allows workarounds without affecting other clients.
Common Outlook Issues
- Images need explicit dimensions or Outlook may resize them
- Line-height requires mso-line-height-rule: exactly
- Buttons work best using VML or table-based approaches
- Background images require VML fallbacks
Image Handling
- Always specify width and height attributes
- Use display: block to remove gaps below images
- Add border="0" for linked images
- Use absolute URLs for images
- Keep file sizes small for faster loading
Skip the Complexity
HTML email coding requires significant expertise and ongoing maintenance as email clients evolve. Sequenzy generates cross-client compatible code automatically, handling all these technical details so you can focus on your message.
HTML Email Coding Coding practice decision table
| Practice | Why it matters | Effort | Where it pays off |
|---|---|---|---|
| Table-based layouts | Client compatibility including Outlook | Low, once templated | Deliverable HTML everywhere |
| Inline CSS final styling | Some clients strip head styles | Tooling does it (MJML / inliner) | Reliable rendering in all clients |
| Preprocessing pipeline (MJML / Maizzle) | Responsive output without raw tables | Setup time, learned once | Maintainable long-term email system |
| Test in real clients | Previews don't equal behavior | Medium | Avoiding the inbox surprise |
A 30-Day HTML Email Skill Plan
- Days 1-3: Inventory current email HTML: what's table-based, what secrets head-only CSS, which templates break in Outlook.
- Days 4-7: Choose a build pipeline (MJML or Maizzle) and convert one existing template end-to-end.
- Days 8-12: Add a preview step: render the template in real clients you care about rather than only a desktop browser preview.
- Days 13-18: Test accessibility: semantic headings, alt text, color contrast; fix the top three issues found.
- Days 19-25: Build a shared snippet library (button, footer, divider) locked down as reusable components.
- Days 26-30: Document the build pipeline — how to edit, preview, and ship a template change — so the team is not dependent on one person's memory.
Dark Mode Is a Coding Problem, Not a Design Problem
Dark-mode email behavior depends on how color values, images, and background declarations are written, not just what they look like in a screenshot. Use CSS custom properties and media queries deliberately (where supported), prefer outlined or transparent-background logos so they don't sit in a surprise white box, and test the compiled HTML rather than trusting a single mock.
Accessibility Is Also a Coding Task
An email's semantic quality — heading order, meaningful alt text, links with purpose, adequate color contrast — lives in the HTML a developer writes. Design tools cannot fix broken heading order on their own. Build accessibility checks into every template's QA checklist rather than treating them as a pre-launch add-on.
HTML Email Coding FAQ
Are table layouts outdated in email HTML?
No — despite modern web CSS, tables remain the compatibility backbone for email because support for flexbox and grid varies unpredictably across clients. Modern pipelines (MJML, Maizzle) output table-based HTML invisibly; hand-coders should too.
Can I use custom fonts in email?
Limited. Web fonts render in some clients (iOS Mail, Apple Mail) but fall back to system fonts in most desktop mail and predictably in Gmail. Always set a readable font stack fallback; design so the fallback view isn't broken if the web font fails to load.
Do I need to support Outlook specifically?
Depends on your audience: B2B-heavy lists often include significant Outlook desktop usage, and it behaves differently from webmail. Check your audience data; if Outlook is meaningful, buy or use a rendering test service and fix the client's specific quirks (image sizing, VML background images, padding collapse).
Is there a limit to CSS support in email clients?
Email supports a subset: inline styles are most reliable; head styles are often stripped (Gmail historically); keyframes and modern selectors largely don't work. Build with the safest subset and test the output in real clients, not IDE code validators.
How do I QA an HTML email without paid tooling?
Manual routes: send test emails to yourself across Gmail web, Gmail mobile, iOS Mail, Outlook desktop, and dark mode. Add Litmus or Email on Acid when a paid rendering service is warranted for volume production — but don't let lack of tooling excuse skipping basic client testing.
Related reading: the email template design guide, email template best practices, and template library.
Choose One Build System and Own It
Mixing hand-written HTML with two pipeline tools (MJML plus Maizzle plus React Email) creates maintenance debt: three ways to write a button is three chances to drift. Pick one system for the team, document its conventions, and add new templates only through that path.
Your CI Should Compile Your Emails
Email source files that require a developer's laptop to build are fragile. Add your email build step to CI (compile templates, run the preview, optionally run the HTML through a validator) so every change is reproducible, reviewable in pull requests, and testable in a clean environment.
Common Mistakes
- Styling entirely in CSS, which some clients strip — inline critical styles at build time.
- Hand-coding tables without a template library — every template rebuilds the same bugs.
- Previewing only in a desktop browser rather than real email clients.
- Images at full upload resolution instead of display size.
- Ignoring Outlook-specific quirks (image sizing, background images, padding collapse).
- Deploying without a plain-text or dark-mode check.
HTML Email Coding Tool chain comparison table
| Stage | Hand-coded tables | MJML | Maizzle | React Email |
|---|---|---|---|---|
| Learning curve | Low to medium (table patterns) | Low-medium (component markup) | Medium (Tailwind knowledge) | Reacts developers fall in fast |
| Output control | Full manual control | Compiled responsive HTML | Utility-class generated HTML | Componentized, exported HTML |
| Client compatibility | Manual effort dominates | Strong track record | Strong similar to MJML | Good, newer library |
| Best fit | One-off simple templates | Most production teams | Tailwind-fluent teams | React-based products |
A 30-Day HTML Email Production Plan
HTML Email Coding FAQ (continued)
Can an email be fully responsive without media queries?
Partly — fluid table widths and max-width constraints give basic responsiveness, but true mobile adaptation (stacking, hiding modules) relies on media queries, which not every client supports. Build the base narrow-first; treat media queries as the enhancement layer.
Why is Outlook desktop such a persistent problem?
Outlook desktop uses Word's rendering engine for HTML email, so it supports a smaller CSS subset and interprets spacing, background images, and image sizing differently. Design conservative layouts, use bulletproof patterns for backgrounds and buttons, and test Outlook versions your audience uses.
Do I need a separate mobile template?
No — one responsive template is the goal. A separate mobile template is a symptom of an unmaintained codebase or a fixed-width design that should have been made fluid from the start.
How do I keep HTML email code readable long-term?
Comment sections, keep one template per file or component, use partials for repeated blocks (header, footer, button), and version-control templates alongside product code. Conserving readable structure matters more than any single build-tool choice.
What should plain-text fallback contain?
An equivalent reading experience: content in logical order, meaningful links spelled out, and the unsubscribe path present. Plain-text is also a legitimate accessibility and deliverability accessory, not just a fallback.
More guides: responsive email templates, dark mode email templates, and the template library.
Preview Early, Preview Often
The highest-value habit in email HTML is frequent real-client checks — send a test message every few edits rather than staging one dramatic final reveal. Bugs between a browser preview and a real client are easiest to catch while the fix is small.
Commit Templates Like Product Code
Source control matters for email more than most people expect: seasons come and campaigns come back, and reproducing last December's template depends on repo history. Keep templates in version control with commit messages tied to the campaign context.
A Coding Checklist for Ready-to-Send HTML
| Item | Why it matters |
|---|---|
| Table-based primary layout | Maximum client compatibility, especially Outlook desktop |
| Critical styles inline | Head styles are stripped by several clients |
| Bulletproof buttons | Renders with or without images, across clients |
| Fallback text and background colors | Email must survive image blocking and CSS stripping |
| Alt text on every content image | Accessibility plus images-off resilience |
Aim for Clarity, Not Cleverness, in Markup
Long-term health of an email system is driven by readable markup: consistent table patterns, comments that clarify unusual choices, and partials for repeated blocks. Clever markup that saves bytes but costs a future debugging session is more expensive than it looks.
Should I document email HTML decisions?
Yes — keep a short README alongside the templates: which build pipeline is used, the key patterns (bulletproof buttons, fallback structure), and where shared snippets live. Next year’s cross-training is documentation-driven, not memory-driven.