What is missing
A way to see how an email will actually render in Gmail/Outlook/Apple Mail without maintaining test accounts or paying for a device lab.
The obvious framing — "write rendering engines that match each client" — is the wrong one, and it fails on a specific thing. Classic Outlook on Windows renders through Microsoft Word's layout engine. The only official documentation is an MSDN article from August 2006 (part 1) that enumerates which CSS properties are supported and then disclaims itself: "this document should not be considered a comprehensive reference guide." It never describes layout semantics — the box model, the table algorithm, the HTML-to-Word-document conversion. No reimplementation exists, open source or otherwise.
Proposed approach
Separate the two things clients actually do. For every modern client the rendering engine is already mainstream — Blink for Gmail web, Outlook.com and Yahoo; WebKit for Apple Mail. What differs is the server-side preprocessing that rewrites the HTML and CSS before any engine sees it.
So: model the transformation, then hand the transformed document to a real engine.
Classifying our own 28 documented quirks against that split:
| Category |
Count |
Tractability |
Pure preprocessing — 102 KB clip, <style> stripping, [data-ogsc], .ExternalClass, @media stripping, iOS auto-linking |
12 |
Deterministic. No engine needed. |
| Render configuration — font substitution, images blocked, DPI, colour scheme |
4 |
Flags on a headless browser. |
| Free from a real engine — 3px image gap, background gutters |
2 |
Blink/WebKit already do these. |
Word engine — max-width, dead click areas, table gutters, line-height leading, DPI upscaling |
~7 |
Not tractable. |
| Legacy Trident, accessibility tree |
3 |
One is dead; one is testable via a11y APIs. |
Roughly two thirds is reachable without writing a renderer.
The direction of travel helps. New Outlook is confirmed Chromium: Microsoft states it "is a native application, based on WebView2. The experience is provided by Outlook on the web" (docs). Classic is supported until at least 2029, so the Word problem shrinks rather than disappears.
Work is split across #32 (Gmail transform), #33 (Outlook.com transform), #34 (render layer), #35 (ground truth + caniemail).
What this must not claim
Not "pixel-identical to Gmail." The honest product is "here is what Gmail will do to your HTML, rendered in Blink." See #35 for why exactness is unverifiable without the very device lab this avoids.
Prior art
No vendor appears to emulate. Mailosaur is the only one stating methodology plainly — previews are screenshots "using physical devices" (docs). Litmus and Email on Acid do not disclose methodology publicly; Litmus's KB is behind auth and Email on Acid now redirects to Mailgun, so treat the widely repeated "real devices, not emulators" claim about them as unverified.
Static analysis against a support database is the only emulation-adjacent approach that exists, and it is already open source: Mailpit runs 175+ checks mapped to caniemail, and vmail does the same. Neither renders. That makes static checking table stakes rather than differentiation — the transformation simulation is the part nobody has built.
Clients it matters for
Gmail (web + apps), Outlook.com / new Outlook, Apple Mail, classic Outlook (partially, and only ever approximately)
What is missing
A way to see how an email will actually render in Gmail/Outlook/Apple Mail without maintaining test accounts or paying for a device lab.
The obvious framing — "write rendering engines that match each client" — is the wrong one, and it fails on a specific thing. Classic Outlook on Windows renders through Microsoft Word's layout engine. The only official documentation is an MSDN article from August 2006 (part 1) that enumerates which CSS properties are supported and then disclaims itself: "this document should not be considered a comprehensive reference guide." It never describes layout semantics — the box model, the table algorithm, the HTML-to-Word-document conversion. No reimplementation exists, open source or otherwise.
Proposed approach
Separate the two things clients actually do. For every modern client the rendering engine is already mainstream — Blink for Gmail web, Outlook.com and Yahoo; WebKit for Apple Mail. What differs is the server-side preprocessing that rewrites the HTML and CSS before any engine sees it.
So: model the transformation, then hand the transformed document to a real engine.
Classifying our own 28 documented quirks against that split:
<style>stripping,[data-ogsc],.ExternalClass,@mediastripping, iOS auto-linkingmax-width, dead click areas, table gutters, line-height leading, DPI upscalingRoughly two thirds is reachable without writing a renderer.
The direction of travel helps. New Outlook is confirmed Chromium: Microsoft states it "is a native application, based on WebView2. The experience is provided by Outlook on the web" (docs). Classic is supported until at least 2029, so the Word problem shrinks rather than disappears.
Work is split across #32 (Gmail transform), #33 (Outlook.com transform), #34 (render layer), #35 (ground truth + caniemail).
What this must not claim
Not "pixel-identical to Gmail." The honest product is "here is what Gmail will do to your HTML, rendered in Blink." See #35 for why exactness is unverifiable without the very device lab this avoids.
Prior art
No vendor appears to emulate. Mailosaur is the only one stating methodology plainly — previews are screenshots "using physical devices" (docs). Litmus and Email on Acid do not disclose methodology publicly; Litmus's KB is behind auth and Email on Acid now redirects to Mailgun, so treat the widely repeated "real devices, not emulators" claim about them as unverified.
Static analysis against a support database is the only emulation-adjacent approach that exists, and it is already open source: Mailpit runs 175+ checks mapped to caniemail, and vmail does the same. Neither renders. That makes static checking table stakes rather than differentiation — the transformation simulation is the part nobody has built.
Clients it matters for
Gmail (web + apps), Outlook.com / new Outlook, Apple Mail, classic Outlook (partially, and only ever approximately)