CSS Inlining for Email: When You Need It, and When You Don't

Why inlining exists

On the web, you put CSS in a stylesheet and elements inherit it. Email clients don't play along. Several, Gmail most famously, strip or ignore <style> blocks in the document head, especially on some mobile and cached views. When that happens, any rule that wasn't written directly on the element vanishes.

Inlining is the workaround: it copies each matching rule onto the element's own style= attribute, where every client reads it. So .btn { color: #fff } plus <a class="btn"> becomes <a class="btn" style="color:#fff">.

What inlining handles for you

• Specificity. When two rules target the same element, the more specific selector wins, an id over a class, a class over a tag, exactly as a browser resolves the cascade. A good inliner flattens that correctly.
• !important. Preserved during the merge, so intentional overrides survive.
• Shorthand and inheritance. The computed declarations land on the element, so you don't lose values to a stripped stylesheet.

What inlining can't move (and why you keep a style block)

Some CSS has no inline equivalent, because an inline style= attribute styles exactly one element and can't express conditions or states:

• Media queries (@media), your responsive and mobile-specific styles.
• Pseudo-classes and elements (:hover, ::before).
• @font-face and keyframe animations.

A proper inliner leaves those in a <style> block rather than dropping them. So the end state is hybrid: most styles inlined for universal support, plus a slim style block for the things that need it. Keep that block, it's what makes your email responsive.

When you don't need to inline by hand

If you build with a framework, inlining may already be happening. MJML and Maizzle inline as part of their build; React Email encourages inline styles from the start. You mostly need a standalone inliner when you're hand-writing HTML, exporting from a design tool, or working with a template that ships a big <style> block.

One caveat worth knowing: inlining repeats declarations onto every element, which inflates your HTML. On large emails that can push you past Gmail's 102KB clip limit, so inline first, then check your size.

Do it in the browser

You can inline any email without a build step: paste it into the CSS inliner, which flattens your styles while preserving media queries. Then confirm the result with the CSS compatibility checker (inlining puts CSS where clients can read it, but doesn't make them support it), keep an eye on weight with the email minifier, and look up any single property in Can I email. For modern utility-first frameworks, read our guide on why Tailwind v4 emails break in Gmail.