Inline CSS for Email: Why Your Styles Need to Move Into the Tags

On the web, you write CSS once in a stylesheet and every page uses it. Email does not work that way. There is no shared stylesheet, no reliable cascade, and no guarantee that the code you send is the code that renders. Each inbox runs its own rendering engine, and several of them rewrite your HTML before showing it.

The biggest reason is that some email clients remove the head entirely, or strip the style block inside it. The classic example is Gmail's older behavior and many webmail clients that drop embedded styles for security and layout reasons. When that happens, any rule you wrote in a style block is gone. A button you styled with a .btn class shows up as plain blue underlined text.

Inline styles dodge this. A style attribute lives on the element itself, so there is nothing to strip without removing the element. When you write <td style="padding:24px; font-size:16px; color:#111111;"> instead of relying on a .cell class, that padding and color travel with the tag into every inbox. This is why production email is table-based with styles inlined on nearly every td, a, p, and img. It looks repetitive because it is, and that repetition is what keeps the email intact.

If you build email by hand, you write the markup with classes for sanity, then run it through an inliner before you send. If you use a tool like Mailwright, the HTML comes out already inlined and table-based, so the pasting step into Klaviyo or Mailchimp does not surprise you later.

It is not all or nothing, and it is not the same in every client, which is what makes this confusing. Three things happen in practice.

Some clients remove the entire head and its style block. Your embedded rules never run. Inlined styles are the only ones that survive.

Some clients keep the style block but ignore specific properties. Older Outlook on Windows uses Microsoft Word's engine to render mail, and Word ignores or mishandles a lot of modern CSS: background images on most elements, position, float, max-width, and many shorthand declarations. So even when your style block is kept, the rule may do nothing.

Some clients keep the style block and respect it, which is why media queries can still work (more on that below). Apple Mail, the iOS Mail app, and modern Gmail apps fall here for a meaningful range of CSS.

The practical takeaway: treat every property you put in a style block as optional, something that might be honored and might vanish. Put anything load-bearing inline. Font size, color, padding, width, text alignment, and link color all belong inline on the element. A useful habit is to set link color directly on the anchor, like <a href="..." style="color:#1a5fb4; text-decoration:underline;">, because clients love to recolor unstyled links, and dark mode often flips them to something unreadable.

Inline styles cannot hold a media query. There is no syntax for style="@media..." on an element. So the rules that make an email respond to screen width have to sit in a style block in the head, which is the same place clients are allowed to strip.

This is the trade you live with. You inline everything you can for durability, then put your responsive rules in a head style block and accept that some clients will ignore them. The pattern that makes this safe is mobile-friendly by default. Build the desktop layout inline so it already works at any width, then use the media query only to improve the small-screen view, not to make it functional.

A common version looks like this. Inline a table cell at a fixed width for desktop, then add a media query that stacks columns and bumps font size on phones:

@media only screen and (max-width:600px) { .stack { display:block !important; width:100% !important; } .mobile-pad { padding:16px !important; } .big { font-size:20px !important; } }

You attach those classes to elements that already have inline styles, and you use !important so the media query can override the inline value when it does run. If a client strips the block, the inline styles still hold and the email is readable, just not stacked. If the client honors the block, the layout adapts. Either way the email works.

This is the reason an email keeps both a class and an inline style on the same element. The class is the hook for the media query. The inline style is the fallback that always renders.

You do not hand-inline a real email. You write it with classes and run an inliner. Common ones include Juice (a Node library, juiceio on the web), the inliner built into MJML and Maizzle, Litmus and Email on Acid's built-in inline tools, and Mailchimp's own inliner when you import a template. They all do the same core job: read your style block, match selectors to elements, and copy the resulting properties into each element's style attribute. Good inliners are smart enough to leave media queries in the head and only inline the non-responsive rules.

The gotchas are consistent across tools. First, inliners flatten the cascade, so a rule that only worked because of selector specificity can change once everything is inline. Keep selectors simple, ideally a class per element, and avoid descendant selectors you are counting on. Second, shorthand can expand in ways Outlook dislikes; writing padding as four longhand properties (padding-top, padding-right, and so on) avoids cases where Word's engine drops the whole declaration. Third, an inliner cannot inline what has no syntax for it, so :hover, ::before, and @media stay in the head and only work where the block survives. Treat all three as enhancements, never as load-bearing.

A few more that cost real time. Background colors set with the bgcolor attribute on a td are more reliable in Outlook than a CSS background, so many teams set both. Image dimensions belong as width and height attributes on the img tag, not only in CSS, because some clients ignore CSS sizing. And test the inlined output, not the source. Litmus and Email on Acid run the actual file through real clients; previewing the pre-inline version tells you nothing about what the inbox sees. If you want to skip most of this, the point of an ESP-safe builder like Mailwright is that it emits the inlined, table-based, tested-pattern HTML for you, so the only thing left is to paste it and send a test.