Web pages and HTML email use the same language — tags, attributes, CSS — but they behave completely differently in practice. Code that shows beautifully in Chrome can collapse in Outlook, lose all its styles in Gmail, or display the wrong colors in Apple Mail's dark mode. this explains the key differences betweenHTML email vs browser HTMLand whyEmail Viewer exists as a separate tool from a standard HTML previewer.
The fundamental difference: showing engines
Modern browsers (Chrome, Firefox, Safari, Edge) share a mostly consistent, standards-compliant showing engine. They support the full range of current HTML5 and CSS3, handle layout with flexbox and grid, and agree on how to parse and display markup.
Email clients use different showing engines — and in some cases, very old ones:
- Outlook 2007–2019 on Windowsuses Microsoft Word's showing engine to display HTML email. Word is not a web browser. It supports a subset of HTML and CSS that was current in 2007 — no flexbox, no CSS grid, no
position: absolutein many contexts, and limited support for modern CSS properties. - Gmailuses its own HTML sanitizer and shows email inside a web interface. It strips CSS properties it does not recognize, strips
<head>styles in some contexts, and in dark mode, auto-inverts colors that it cannot determine are intentional. - Apple Mailuses a WebKit-based shower — the closest to a real browser, with full support for modern CSS and responsive rules including dark mode.
- Yahoo Mailsanitizes HTML and CSS similarly to Gmail but with its own specific quirks.
The practical result: email HTML must be written to the lowest common denominator of all these clients if you want reliable showing across your entire list.
CSS: what works, what does not
This is the biggest practical difference between web HTML and email HTML.
- Flexbox and CSS Grid— not supported in Outlook on Windows, which is still widely used in corporate environments. Email layout must use tables.
<style>blocks in<head>— stripped by some Gmail contexts and partially supported elsewhere. The safest approach is toinline all critical CSS directly on elements.- Media queries— supported by Apple Mail and some Gmail/Outlook versions, but not universally. Use them for mobile-responsive improvements, but do not rely on them for core layout.
- CSS custom properties (variables)— not supported in any major email client.
- Shorthand properties—
padding: 10px 20pxandfont: bold 14px/1.5 sans-serifare partially supported. Use longhand properties (padding-top,font-weight,font-size) for reliable showing. - Background shorthand— use
background-colorinstead of thebackgroundshorthand for Outlook compatibility.
JavaScript: not available in email
JavaScript is blocked by every major email client. This is a security decision — email is an untrusted channel, and executing scripts from emails would be a significant attack vector. The practical implication: any interactivity in your email must be done with CSS only (hover states on buttons that support it) or with static content. There are no event listeners, no dynamic page structure, no animations driven by JavaScript.
Layout: tables, not flexbox
Web layout has moved to flexbox and CSS Grid — clean, flexible, maintainable. Email layout is still largely built with<table>elements because tables show consistently in Outlook's Word-based engine where modern layout CSS does not.
Writing table-based email HTML by hand is tedious. This is the main reasonMJML exists — it is a component-based framework that converts to table-based HTML, letting you write clean markup that generates the complex table structure automatically.
Dark mode: different behavior per client
Dark mode in email is not controlled by a single CSS property. Each client handles it differently:
- Gmail auto-inverts colors
- Apple Mail applies
prefers-color-scheme: darkresponsive rules if present - Outlook on Windows has its own override behavior
How Email Viewer bridges the gap
Because email HTML behaves so differently from web HTML, a standard browser preview is not enough. Email Viewer applies client-style simulations — showing your HTML with the constraints and overrides of each email client — so you can see what your email actually looks like before sending.
Email Viewer also includes CSS inlining, an HTML compatibility check (flagging CSS properties with limited client support), a pre-send QA checklist, dark mode testing, and mobile preview — all the tools needed to go from an HTML email file to a confident send.