Crosspost note. Originally published at min8t.com/articles/inline-css-for-email. I'm one of the maintainers of MiN8T, which makes the in-browser CSS inliner referenced at the end. The technical content here applies regardless of which inliner you reach for.
You write CSS in a <style> block, the way you have for two decades on the web. You hit send. Half your subscribers see your beautiful design. The other half see something else: a colorless wall of text, a stack of mis-aligned images, a call-to-action that has lost its rounded corners and bright background and is now indistinguishable from the body copy.
The reason: most email clients strip or partially strip <style> blocks. Gmail mobile, Yahoo, AOL, several enterprise clients. They discard your stylesheet entirely. The fix is older than the problem: inline every style as a style="..." attribute on the element it targets. Inline styles are the only CSS form that every email client supports without exception.
This guide walks through exactly what inlining does, what you can't inline (and what to do with those rules instead), the specificity gotchas that produce the wrong output, and a free in-browser tool that handles the whole thing correctly.
1. Why Email Needs Inline CSS
The same HTML and CSS that renders cleanly in any modern browser becomes hostile inside an email client. Email clients are not browsers. They are a patchwork of rendering engines spanning four decades of decisions, and most of them treat your <style> block as a suggestion rather than a contract.
What gets stripped, where
The behavior varies by client. Roughly:
-
Gmail web (large viewport): keeps
<style>blocks in<head>. Strips them in some forwarded contexts. -
Gmail mobile (Android + iOS): strips most
<style>blocks. The same campaign that looks fine on desktop Gmail can render unstyled on mobile. - Outlook desktop (Windows, 2007â2019): renders through Microsoft Word's HTML engine. Honors a small subset of style rules; ignores everything modern (flexbox, grid, transforms, transitions, custom properties, etc.).
-
Outlook on the web: closer to a modern browser; honors
<style>in head. -
Apple Mail (iOS + macOS): the most permissive major client. Honors
<style>blocks fully. -
Yahoo, AOL, Outlook 2003 and below, several enterprise clients: strip
<style>blocks entirely.
Inline styles, styles written directly on an element via the style attribute, are the only CSS form supported by every email client without exception. That's why "inline your CSS before sending" is the universal pre-send hygiene step for HTML email.
If you only remember one rule from this article: inline CSS is the lowest-common-denominator form that every email client respects. Everything you ship to an inbox should pass through an inliner unless you have a build pipeline that already does it.
2. What Inlining Actually Does
An inliner takes HTML with a <style> block and emits the same HTML with each rule's declarations transferred to style="..." attributes on the elements that match. The structure stays identical; only the way styles are attached changes.
A minimal example. Before inlining:
<style>
.btn {
background: #28ef91;
color: #2b312c;
padding: 12px 24px;
border-radius: 999px;
}
</style>
<a class="btn" href="...">Read more</a>
After inlining:
<a class="btn" href="..."
style="background: #28ef91; color: #2b312c; padding: 12px 24px; border-radius: 999px;">
Read more
</a>
The rule is gone from the <style> block; the same declarations now live on the element. Yahoo, Gmail mobile, and every other style-stripping client now render the button correctly because the styles are attached to the element they target.
The browser does most of the work
An inliner doesn't need to parse CSS from scratch. Modern browsers expose every parsed rule via document.styleSheets. A well-built inliner loads the user's HTML into a sandboxed iframe, walks the parsed rules, computes which elements each selector matches via querySelectorAll, and writes the matching declarations as inline styles. The browser handles selector parsing, specificity, and rule expansion; the inliner just orchestrates.
3. What You Cannot Inline (And What To Do Instead)
Not every rule can be inlined. Four categories of CSS depend on living in a <style> block, and a competent inliner leaves them there.
1. @media queries
A media query says "apply this rule conditionally." That conditional logic doesn't translate to an inline attribute. An attribute fires unconditionally. @media (max-width: 600px) is your responsive-email lifeline; it's how you stack columns vertically on mobile and resize hero images. Leave the <style> block intact for these. Apple Mail, Gmail web (large viewport), and modern Android Gmail all honor @media queries inside <head> <style>.
@media (max-width: 600px) {
.col { width: 100% !important; display: block !important; }
}
2. Pseudo-classes (:hover, :focus, :active)
Inline styles have no concept of state. Writing style="color: red" inside an <a> applies that color always, not just on hover. So a:hover { color: red } can't be inlined; it has to stay in the <style> block. Apple Mail, Gmail web, and Yahoo support hover; Outlook desktop ignores it; the rule is harmless either way.
3. Pseudo-elements (::before, ::after)
The same logic. ::before creates a virtual element at parse time; an inline attribute can't simulate that. Pseudo-element rules stay in the <style> block. Be aware that Outlook desktop strips them entirely.
4. @keyframes, @font-face, @supports, @import
All four are at-rules with no element to attach to. They live in the <style> block (or in some <link> elsewhere) by definition. @keyframes animations work in Apple Mail, Gmail web, and Yahoo, useful for subtle motion. @font-face works in Apple Mail and Outlook on the web; web fonts are stripped from Outlook desktop and Gmail mobile. @supports is rarely useful in email but harmless. @import is dangerous because remote stylesheet loads are mostly stripped by privacy-conscious clients.
The pattern: a good inliner inlines what it can, preserves the rest
The output should always be:
- Element-targeted rules, inlined as
style="..."attributes. - Conditional + state-dependent rules, left in the
<style>block, untouched. - Existing inline styles in your input, preserved unless an
!importantrule from a<style>block overrides them.
4. Specificity and the Cascade: The Rule That Trips People Up
When two rules in your <style> block both target the same property on the same element, only one wins. CSS specificity decides which. Most cheap inliners get this wrong.
The specificity tuple
Per the CSS Selectors L3 spec, every selector has a specificity score expressed as a 3-tuple (a, b, c):
-
a = count of
#idselectors -
b = count of
.class,[attr], and:pseudo-classselectors - c = count of element types and pseudo-elements
Comparison is lexicographic: (1, 0, 0) beats (0, 99, 99). (0, 1, 0) beats (0, 0, 99).
An example that goes wrong
Consider:
<style>
.promo { color: orange; }
#hero { color: green; }
</style>
<p class="promo" id="hero">Sale</p>
What color is the text? Green. The id selector #hero has specificity (1, 0, 0); the class .promo has (0, 1, 0). ID wins. A naive inliner that just walks rules in source order would write style="color: green" first then style="color: orange", leaving orange as the final inline value. Wrong.
!important overrides specificity
An !important declaration beats any non-important declaration regardless of specificity. So:
.promo { color: orange !important; }
#hero { color: green; }
now resolves to orange. Inliners that don't track !important separately will get this case wrong too.
Existing inline styles also count
If your input HTML already has style="color: yellow" on the element, that inline value has effective specificity (1, 0, 0, 0). It beats anything in the <style> block except !important rules. A correct inliner preserves existing inline styles by default and only overrides them when an !important rule has a higher claim.
Why most cheap inliners get this wrong
The naive implementation walks <style> rules top-down and writes each one as inline styles, letting "later writes win." That works only for simple cases. Once you have IDs, classes, and inline styles competing for the same property, last-write-wins produces output that doesn'et match what the browser would render. Test your inliner output against the browser's getComputedStyle() to verify.
5. Build-Time vs Paste-Time Inliners
There are two ways to inline CSS for email. Pick by workflow.
Build-time (juice, MJML, Maizzle, Mailgun's library)
You wire an inliner into your build pipeline. Source HTML lives with <style> blocks; the build emits inlined output. Best when:
- You ship many emails on a recurring schedule (transactional, drip campaigns).
- You version-control your email source.
- You want each campaign's HTML to be reproducible from source.
The downside: setup. You need a Node + build pipeline; you're committing to a specific tool's output style.
Paste-time (browser-based inliners)
You paste HTML into a textarea, get inlined output back, copy it to your ESP. Best when:
- You're sending one-off campaigns or last-minute fixes.
- The HTML came from a no-code tool that doesn't have its own build step.
- You're QA-ing an export from someone else's pipeline.
- You want zero install + zero learning curve.
For most email teams that aren't running a fully-automated send pipeline, paste-time is the realistic everyday choice. The build-time approach pays off only when the same template ships repeatedly.
6. Edge Cases and Gotchas
The Gmail 102 KB clip threshold
Gmail clips emails larger than 102 KB of HTML/text content (images don't count) and shows a "View entire message" link to expand. Anything below the clip is invisible by default, which is bad for tracking pixels at the bottom of the email and bad for unsubscribe links that fall below it. Inlining grows file size because the same rule may be repeated as inline styles across many elements. A good inliner reports the final size and warns if you cross 102 KB. If you're over, the fix is usually to remove unused selectors before inlining, or to use a build-time inliner that supports tree-shaking.
CSS shorthand expansion
When the browser parses border: 1px solid black, it expands the shorthand into border-top-color, border-top-style, border-top-width, and the same for the other three sides. Naively-implemented inliners then write 12 inline declarations where 1 would suffice, bloating output 5â10x. Better inliners keep the shorthand or compress longhand back to shorthand.
CSS variables (var(--x))
Most email clients don't support custom properties. Outlook desktop and Gmail mobile ignore them entirely. Apple Mail and Outlook web do support them. If your source uses CSS variables, the inliner should resolve them to literal values during inlining; otherwise your inline styles will be color: var(--brand) which falls back to invalid in unsupported clients.
Pseudo-class rules with the same selector
If you have a { color: black } a:hover { color: blue }, only the first rule should be inlined; a:hover stays in the <style> block. A buggy inliner that splits selectors on comma but not on pseudo-class boundaries will erase the hover rule entirely.
External stylesheet <link> tags
Most clients strip external stylesheets, they don't load the URL at all. Inliners that try to fetch the linked stylesheet to merge it into the inline output run into CORS issues. The pragmatic answer: don't ship <link rel="stylesheet"> in email at all. Embed every rule in a <style> block in <head>, then inline.
7. Try It Now (Free, In Your Browser)
The MiN8T CSS Inliner does everything described above. It runs entirely in your browser, nothing is uploaded. It uses your browser's native CSS engine for parsing and selector matching, which is more accurate than any custom parser, and it correctly handles specificity, !important, pseudo-classes, @media preservation, and existing inline styles.
What to do after inlining
Inlining is one step in a pre-send pipeline. The full check before you ship:
- Inline CSS, the topic of this article.
- Verify rendering across clients. Free option: paste into a free preview tool. Paid option: Litmus or Email on Acid for pixel-perfect Outlook rendering.
- Score the spam triggers with a content scanner that runs SpamAssassin-style rules with a per-rule breakdown.
- Verify auth records separate from the content side. Spam filters care about content + sender reputation + SPF/DKIM/DMARC alignment. The first is in this article; the rest is the deliverability stack.
If you write MJML or use a build pipeline
You probably don't need a paste-time inliner. MJML inlines on compile, and most email frameworks (Maizzle, Foundation for Emails, etc.) include an inliner step. Use any MJML-to-HTML converter for quick MJMLâHTML compilation in the browser, then run the result through a CSS Inliner if you want to verify the inline output independently of MJML's own choices.
Putting it all together
Inlining is a five-second pre-send step that prevents 80% of cross-client rendering issues. Combined with a quick visual verification, a content score, and DNS auth (SPF/DKIM/DMARC, separate work), you cover the entirety of the designâdeliverability stack. None of this should require a paid tool. The whole pipeline is free in your browser.
Originally published at min8t.com/articles/inline-css-for-email. I work on MiN8T, an email infrastructure, design, and deliverability platform. Questions or counter-examples in the comments welcome.