SendReady
← Blog
email-developmentcssesp

How CSS Inlining Works — And Why Your ESP Requires It

May 14, 2026

Every email developer eventually hits the same wall: an email that looks perfect in the browser renders as unstyled text in Gmail. The fix is CSS inlining, one of the most fundamental concepts in email development and one of the most misunderstood.

Why email clients strip your CSS

When you write a web page, you put your CSS in a <style> block in the <head> or in an external stylesheet. The browser reads it, applies it, and renders your page. This is entirely standard.

Email clients don’t work this way. Gmail, the most widely used email client in the world, strips <style> blocks from any HTML it renders. This behavior is intentional. Allowing arbitrary CSS in emails would enable layout attacks, CSS injection, and unpredictable rendering across Gmail’s many surfaces: web, iOS, Android, and the Google Workspace apps. By removing <style> blocks, Gmail ensures consistent rendering and prevents styling from leaking across the inbox interface.

Outlook on Windows takes a different approach but reaches the same result: it uses Microsoft Word as its rendering engine, which supports only a limited subset of CSS and ignores much of what you’d put in a <style> block anyway.

Yahoo Mail, AOL, and many corporate mail clients have similar restrictions. The result is that the only CSS that works everywhere (reliably, without exception) is CSS written directly on each element as an inline style attribute.

What CSS inlining does

A CSS inliner reads your HTML, parses every rule in your <style> block, and applies those rules directly to each matching element. What was written as:

<style>
  p { font-size: 16px; color: #333333; line-height: 1.6; }
  .cta { background-color: #1D9E75; color: white; padding: 12px 24px; }
</style>

<p>Welcome to our newsletter.</p>
<a class="cta" href="#">Read more</a>

Becomes:

<p style="font-size: 16px; color: #333333; line-height: 1.6;">Welcome to our newsletter.</p>
<a style="background-color: #1D9E75; color: white; padding: 12px 24px;" href="#">Read more</a>

The <style> block is removed (or optionally kept for clients that do support it). Every CSS declaration is now directly on the element, where every email client can read it.

What gets preserved and what doesn’t

CSS inlining can only handle element-level styles. Several types of CSS rules cannot be inlined and require a different approach:

Media queries: these are conditional blocks that can’t be scoped to a single element. A good inliner keeps them in a <style> block in the <head> so clients that support them (Apple Mail, modern Outlook on Mac) can use them. Clients that strip <style> blocks simply fall back to the inlined styles.

Pseudo-selectors: :hover, :focus, :first-child, and similar selectors are state-based or structural. They can’t be inlined because they depend on runtime conditions. These are kept in the <style> block for clients that support them.

Keyframe animations: @keyframes are not inlineable and stay in the <style> block. Most email clients ignore them anyway.

Why you should inline before uploading to your ESP

Most ESPs, including Mailchimp, Klaviyo, HubSpot, Campaign Monitor, and Salesforce Marketing Cloud, accept raw HTML. Some apply their own CSS inlining during the send process, but their implementations vary. You have no visibility into what they strip or transform, and you can’t verify the output before it reaches your list.

Inlining your CSS before uploading gives you full control and lets you review exactly what your subscribers will see. It also catches specificity conflicts and missing declarations before they reach the inbox.

The workflow

  1. Write your email template with a clean <style> block in the <head>.
  2. Run it through a CSS inliner: SendReady’s CSS Inliner does this in the browser, with no upload required.
  3. Optionally run the output through an HTML Minifier to reduce file size.
  4. Upload the inlined HTML to your ESP.

Keep your pre-inlined source file. That’s the one you’ll edit for future versions. Editing inlined HTML directly is painful and error-prone.

  • HTML Minifier: Reduce file size after inlining to stay under Gmail’s 102KB clip limit.
  • Spam Word Scanner: Flag deliverability risks in your copy before you send.