“Just copy the header from the website,” they said. “It’s all HTML anyway, right?”
It sounded logical, until the header layout shattered in Outlook, the fonts defaulted in Gmail, and the background image didn’t load at all in Apple Mail. That was the day I stopped calling HTML email a web page.
Email might be made of HTML and CSS, but it plays by a different rulebook. If you treat it like a browser, it will break, and your audience will notice. Here’s why email is its own thing, and how we can all respect it more.
It’s Not Just the Language, It’s the Landscape
Email uses HTML and CSS, yes. But:
There’s no consistent rendering engine
No universal support for modern CSS (like Flexbox or Grid)
No JavaScript, period
No guarantees that stylesheets in the <head> will even be read
So while the markup *looks* like the web, the behavior is completely different.
The Web Has a Standards Body. Email Has… Chaos.
Browsers evolve. They have spec updates. Dev tools. Debuggers. Feature flags.
Email clients? You get Gmail, Outlook, Apple Mail, Yahoo, Samsung, each with their own quirks, hacks, and rendering logic. No consistent spec. No unified engine. No reliable baseline.
That means devs have to code for the lowest common denominator, often using techniques that would be outdated on the web, but are *critical* in email.
What Makes Email Different
1. Tables Rule the Layout
While the web moved on to Flexbox and Grid, email still depends on <table> for layout, because they render more predictably across clients.
2. Inline CSS is Mandatory
Most email clients strip out <style> tags. So we inline everything:
3. Dark Mode Is Inconsistent
Apple Mail, Outlook.com, and Gmail on mobile will invert colors, sometimes badly, unless you actively guard against it.
4. JavaScript? Forget It.
Want a dropdown? Dynamic form validation? A toggle interaction? Nope. Email doesn’t allow it. You have to simulate everything with static HTML.
5. Fonts and Images Must Have Fallbacks
Web fonts are partially supported. Images might be blocked by default. You need:
System-safe font stacks
Descriptive alt text
Visible CTAs even if images fail
Why It Matters
If you treat email like a webpage, you’ll ship broken layouts. Unreadable text. Misaligned buttons. Invisible CTAs.
But if you treat email like its own discipline, with its own constraints, tools, and patterns, you’ll ship consistently polished, accessible, high-performing messages that actually make it to the inbox intact.
What Developers Should Know
Start with a boilerplate (not from scratch)
Use email-specific frameworks like MJML, Maizzle, or custom table stacks
Test in real inboxes (not just your browser)
Respect Outlook and Gmail as different beasts
Include a plaintext version
What Designers Should Know
Design for ~600px wide emails
Start mobile-first or provide mobile mocks
Use safe font stacks and provide fallback colors
Keep layouts linear and stack-friendly
Mark up spacing as padding, not just whitespace
And What Marketers Should Know
Last-minute copy edits can break layout
Subject line + preview text = first impression
Don’t skip testing, even if “it looks fine in the browser”
Email dev takes time, not because it’s inefficient, but because it’s cautious
Final Thought: Respect the Medium
HTML email is not a downgraded website. It’s a specialized tool, and one of the most intimate, high-ROI channels in the digital world.
When everyone on the team treats it with the care it deserves, the difference shows, in performance, in consistency, and in brand trust.
Still thinking it through? Contact me here and I’ll help you get it right.