If you've spent time building websites and decided to try building an HTML email, you've probably had one of two experiences: mild confusion followed by frustration, or immediate frustration followed by deeper frustration.
Email HTML development is unusually difficult, and it's not because developers aren't smart enough. The reasons are structural. Here's what you're actually dealing with.
Email clients are not browsers
A web browser is a program with a very specific job: render HTML, CSS, and JavaScript correctly according to published web standards. Browser makers compete on correctness, performance, and features. When one browser fails to render something standards-compliant, it's considered a bug.
Email clients have a different primary job: deliver messages securely. HTML rendering quality is often an afterthought, a secondary feature built around the more important jobs of spam filtering, message retrieval, and notification delivery.
This means email clients have never felt the same competitive pressure to improve HTML rendering that browser makers have. Some never bothered to update their rendering engines at all.
Outlook is the most-used email client on many B2B lists — and it uses Word
Outlook on Windows (2007 through 2021) renders HTML email using the Microsoft Word rendering engine. Not Internet Explorer. Not Edge. Word.
Word was designed to create documents, not render web pages. It has limited CSS support, no JavaScript, and its own unique collection of rendering behaviors. Background images don't work. CSS border-radius doesn't work. Flexbox doesn't work. The list of missing features is extensive.
If your email list includes significant business email usage, a substantial portion of your recipients are seeing your emails through a renderer that hasn't meaningfully improved since 2007.
CSS support is inconsistent and undocumented
On the web, MDN documents CSS property support across browsers. caniuse.com shows at a glance which browsers support what.
For email, the equivalent is caniemail.com — built and maintained by community volunteers, covering only a subset of email clients, and often relying on manual testing rather than automated verification. It's valuable, but it's incomplete, and the data can become outdated when clients update without public changelog notes.
Email clients strip your <head> styles
Most email clients (Gmail is the most well-known example) remove or ignore CSS in <style> blocks in the email's <head>. This is partly a security measure to prevent one email's styles from affecting the inbox UI.
The consequence: every CSS rule that needs to apply to email elements must be inline. Every <td>. Every <p>. Every element needs style="" attributes repeating the same font families, font sizes, and colors across hundreds of elements.
This isn't just annoying — it makes emails significantly larger and harder to maintain.
Responsive design works, but differently
Media queries for responsive layout work in many email clients but not all. The pattern that emerged is "fluid-hybrid" layout: use percentage-based widths with max-width constraints so emails can adapt to different screen widths without media query support, then use media queries for additional refinements in clients that support them.
Table-based layout is still required for the responsive patterns to work across all clients. You cannot use display: flex or display: grid for layout.
JavaScript doesn't exist
There is no JavaScript in email. Every interactive pattern that web developers take for granted — form validation, dynamic content loading, real-time updates, dropdowns, tabs — none of it exists.
Some limited CSS-based interactivity is technically possible in a small number of email clients using the CSS checkbox hack or similar techniques, but the support is narrow and the techniques are fragile.
What this means in practice
Building email HTML correctly means:
- Table-based layout for all structural positioning
- Inline CSS on every element
- MSO conditional comments for Outlook-specific behavior
- VML for background images in Outlook
- VML for reliable button rendering in Outlook
- Testing in actual email clients, not just browsers
- Accounting for Gmail's 102KB clipping limit
- Never relying on JavaScript
- Treating CSS support as uncertain until tested
This is why professional email developers have specialized knowledge that isn't obvious from web development experience, and why email component libraries like this one exist — the techniques have been worked out, and the patterns can be reused.
It's getting better, slowly
There are signals of improvement. Gmail has added support for more modern CSS features over time. Outlook on Windows is being replaced with a new Chromium-based client on some distributions. Apple Mail has historically been the most capable email client for modern CSS.
The email development community at Email Geeks Slack and resources like caniemail.com continue to document what works and push for better standards. But for the foreseeable future, cross-client HTML email still requires the table-based, inline-style approach.