Get Started

CSS Inlining in Email: Why It Matters and How to Get It Right

Published

Why your email CSS keeps disappearing

You style an email with a clean <style> block in the <head>, everything looks perfect in preview, you send it — and in Gmail the styling is simply gone. Plain text, default fonts, no colors. You didn’t do anything wrong. The client removed your styles before rendering.

This is one of email’s most counterintuitive rules: a <style> block is not reliable. Several major clients strip or ignore it. The technique that survives is inline CSS — styles written directly on each element’s style attribute. Understanding why, and how to do it well, is essential to shipping email that looks the way you designed it.

Why clients strip <style>

On the web, you almost never write inline styles — you put CSS in an external file or a <style> block and let the browser apply it. Email clients don’t play by those rules, for a few reasons:

  • Security and sanitization. Webmail clients like Gmail run inside a larger page (your inbox). A <style> block in an email could, in principle, leak out and restyle the surrounding interface. To prevent that, clients sanitize incoming HTML — sometimes stripping <style> entirely, sometimes rewriting or prefixing selectors.
  • Historically inconsistent support. Gmail’s clipping and sanitization, older webmail engines, and various mobile apps have all handled <head> styles differently over the years. Inline styles, applied per element, are the one thing every client respects.
  • No external stylesheets at all. <link rel="stylesheet"> to an external CSS file is effectively dead in email — clients won’t fetch it. So the only two options are a <style> block (unreliable) or inline styles (reliable).

The practical takeaway: anything that must render has to be inline. A <style> block can still be useful for things inline styles can’t express (media queries, :hover, pseudo-elements), but those are treated as progressive enhancements — nice when they work, never depended on.

What inline CSS looks like

Instead of a shared rule in the head:

/* Unreliable in email */
.button { background: #2563eb; color: #ffffff; padding: 12px 24px; }

Every element carries its own styles directly:

<!-- Reliable in email -->
<a href="#" style="background:#2563eb;color:#ffffff;padding:12px 24px;">Button</a>

Now multiply that across every text block, every cell, every button, in a table-based layout, and you can see the problem. Inlining by hand is tedious and easy to get wrong — miss one element and it renders with the wrong styles in exactly the clients that strip <style>.

The hidden costs of doing it by hand

Inlining isn’t just repetitive. It creates a set of downstream problems:

  • Duplication. The same styles are repeated on dozens of elements, so a single design change means editing every copy.
  • Bloat. Repeated inline styles make the HTML much larger — which pushes you toward Gmail’s clipping threshold. See Why Gmail Clips Your Emails.
  • Drift. When styles live in dozens of places, it’s easy for them to fall out of sync and for the email to look subtly inconsistent.
  • What can’t be inlined. Media queries and interactive states can’t be expressed inline — they still need a <style> block, so you end up maintaining both.

How to get it right

The professional workflow separates how you write CSS from how it ships:

  1. Author styles cleanly in a <style> block or a component system while you build — it’s readable and maintainable.
  2. Run an inliner as a build step that walks the HTML and copies each applicable rule onto the matching element’s style attribute.
  3. Keep media queries and :hover in a <style> block as progressive enhancement, since they can’t be inlined.
  4. Minimize the output so repeated inline styles don’t bloat the file past the clipping limit.

That’s the standard toolchain email developers assemble by hand. The alternative is to use a tool that does it automatically.

How Temway and MJML handle inlining

You don’t have to run an inliner or maintain two copies of your CSS. Temway renders every design through an MJML engine, and MJML handles inlining as part of compilation. You style your blocks visually — fonts, colors, padding, alignment, button radius — in the properties panel, and on export Temway produces HTML with styles already inlined on each element, plus a <style> block for the responsive media queries that keep columns stacking on mobile.

Because the inlining happens automatically and consistently, you avoid the duplication, drift, and bloat that come with hand-inlining — and the same inlined output is what gets downloaded, test-sent, and pushed to your ESP, so it renders identically everywhere. For an introduction to the language doing this, read What Is MJML?.

Where to go next