Why Marketing Emails Need Their CSS Inlined, and Who Does It For You
Most email clients strip <style> blocks from HTML email. Editor's CSS inliner rewrites your campaign's styling directly onto each element so it survives — here's why that step is necessary at all.
"Why does my email look broken in Outlook" is one of the most durable, evergreen questions in email marketing — every major email service provider has published some version of an explainer on it, because the underlying cause never really goes away: most email clients strip <style> blocks out of HTML email entirely, or apply them unreliably enough that you can't depend on them. A <style> tag that works perfectly in a browser preview can simply not exist as far as Outlook, or a number of other clients, are concerned by the time your email actually lands in an inbox.
The workaround the industry settled on
The fix that's become standard across email marketing tooling is CSS inlining: instead of defining styles in a separate block and letting the browser (or email client) apply them by selector, you rewrite every style directly onto the specific HTML element it applies to, as an inline style="..." attribute. An email client that strips <style> blocks can't strip styling that's already sitting directly on the tag — there's nothing separate to strip.
Where this happens in Piskes
Editor does this automatically as part of sending a campaign, through a dedicated CSS inliner (frontend/apps/editor/src/lib/email/css-inliner.ts). The module's own header comment states its purpose directly: it's "used by campaigns to ensure email HTML renders correctly in email clients that strip <style> blocks." It handles the range of selector types you'd actually write in a template — ID selectors, class selectors, and element selectors — converting all of them into inline styles on the matching elements before the email goes out.
Why this matters even though you'll probably never think about it
The honest reason this is worth writing about at all is that it's invisible when it works. You write your campaign template with normal CSS, the way you'd style any HTML, and the inliner handles the conversion in the background — you never see a <style> block turn into a pile of inline attributes, because that transformation happens automatically before send. The only time this step becomes visible is when it's missing: an email that renders fine in your own inbox because your client handles <style> blocks gracefully, and then looks broken to a meaningful chunk of your recipients using a client that doesn't.
Most products that promise "beautiful email templates" don't explain this part — they just show you a template gallery and leave the actual reason your email renders correctly across clients as an implementation detail nobody talks about. It's worth knowing it's there, mostly so you can trust that writing normal CSS in a campaign template is safe, rather than needing to hand-inline your own styles the way you'd have had to a decade ago.