Email Editors Optimized for Weakest Inbox
Jason Charnes, Staff Product Developer at Podia, on building an email editor
Choosing PNG over SVG shows that email builders are forced to optimize for the weakest important inbox, not the best browser. Podia was shipping a tool for creators who expect emails to render the same way everywhere, so the safe path was to use image formats and layout patterns that old Outlook versions and other lagging clients would actually display. That same logic pushed the team toward inline CSS and heavy table layouts, because email HTML is still closer to 2000s web development than modern app UI work.
-
The practical workflow was, write simple HTML and CSS, run it through Roadie to inline styles, paste the compiled output into Litmus, then check screenshots across target clients. That meant most fixes happened in CSS choices and fallback assets, not by redesigning the editor itself.
-
Can I Email makes this a feature by feature decision. Its current support page shows SVG image support is still not universal, while PNG is broadly safe, so icons are a classic place where teams trade crisp vector assets for predictable rendering.
-
This is a common divide in email tooling. Teams like Zapier and Parcel users invest in reusable components and design systems, but those systems still have to compile down to old school email code, so modern editing UX sits on top of very conservative output.
Email editors will keep getting more visual and more component driven, but the generated code will stay constrained by Outlook and other legacy clients. The winning products will hide that ugliness from creators, while quietly turning every button, icon, and layout block into the safest possible HTML that can survive the inbox gauntlet.