Designing Email Editors for Inconsistent Clients
Jason Charnes, Staff Product Developer at Podia, on building an email editor
The hard part of building email software is not editing HTML, it is surviving a fragmented rendering stack that changes by client, device, and Outlook version. For Podia, that meant the editor could not promise web-like fidelity. It had to generate stripped down, table heavy markup, inline most styles, and then be tested in screenshot tools because the same email could break in classic Outlook on Windows, newer Outlook variants, and Gmail mobile apps in different ways.
-
Classic Outlook on Windows has long used Microsoft Word to render emails, which is why email developers avoid normal web layouts and fall back to old patterns like nested tables and inline CSS. Podia used Roadie to inline styles and explicitly chose PNGs over SVGs for broader support.
-
The inconsistency is not just Microsoft versus everyone else. Gmail documents support for many CSS selectors and media queries, but support still differs across Gmail surfaces, and Can I Email shows large gaps across Outlook variants. Apple Mail supports far more HTML and CSS features, which is why emails often look best there first.
-
This is why Podia bought a preview tool instead of trying to perfect rendering by inspection. The workflow was compile HTML, paste it into Litmus, and review screenshots for a selected list of clients. That was enough to catch major bugs and decide which long tail environments were not worth supporting.
The next step for creator platforms is not making email clients behave, it is narrowing the design space so more emails render safely by default. The winning products will ship opinionated blocks, automatic inlining, and built in QA, so creators can drag together emails that are boring under the hood but reliable in the inbox.