Why does my CSS work in the browser but not in the SendGrid email?

Browsers render your full HTML document including the block. Most email clients (Gmail, Outlook.com, Yahoo) strip the and body tags, discarding embedded rules and any classes that depend on them. Inline the styles directly onto each element so they survive.

Does SendGrid strip CSS classes from my templates?

It can. A documented SendGrid issue shows the Design/Code Editor saving as , removing the class attribute. Sending pre-built raw HTML through the Mail Send API is commonly reported to avoid this, though that isn't explicitly confirmed in the bug report — and email clients may still strip styles regardless, so inline CSS is the safest approach either way.

Do I have to inline every style by hand?

No. Author normal CSS and run the HTML through an inliner such as juice (Node) or premailer (Ruby/Python) before sending. Media queries and :hover can't be inlined, so keep those in a block as progressive enhancement on top of inlined base styles.

SendGrid

sendgrid css not working

Email CSS not rendering in SendGrid? Clients strip head <style> blocks and classes. Learn why, and how to fix it with inline CSS and table layouts.

Updated Jul 1, 2026

The short answer

"SendGrid CSS not working" isn't an SMTP error — it means your email's styling renders wrong or disappears in inboxes. The usual cause: email clients (and SendGrid's template editor) strip <style> blocks from the <head>, so CSS classes never apply. Fix it by inlining your CSS onto each element, using table-based layouts, and testing across Gmail, Outlook, and Yahoo.

"SendGrid CSS not working" is not an SMTP or API error code — it's a rendering symptom. Your email sends successfully, but the styling looks broken, unstyled, or inconsistent depending on which inbox opens it. The cause is almost always how email clients (and, in some cases, SendGrid itself) handle CSS, not a bug in your send.

Why isn't my CSS working in SendGrid emails?

There are two distinct layers stripping or ignoring your styles:

1. Email clients strip <head> and <style> blocks. Per SendGrid's own cross-platform design guide, "Most webmail clients (Outlook.com, Yahoo.com, Gmail, etc.) will strip CSS out when stripping the head and body tags." Many clients wrap your message in their own HTML document and discard your <head>, so any <style> rules and the classes that depend on them simply vanish. This is the single most common reason class-based styling looks fine in a browser but fails in the inbox.

2. SendGrid's template editor can drop class attributes. A documented SendGrid issue (sendgrid/docs #1938) reports that pasting markup like <div class="test"> into the Design/Code Editor can save as <div> — the class attribute is removed, so even a surviving <style> block has nothing to match. Sending pre-built raw HTML through the Mail Send API is commonly reported to avoid the code-editor's class-stripping, though this isn't explicitly confirmed in the bug report — the underlying client-side head-stripping described above still applies regardless of send method.

On top of that, individual clients ignore specific properties even when CSS survives:

Outlook (desktop, Word-based engine): does not support padding on many elements, float, or margin reliably.
Outlook.com / Hotmail: historically ignores margin; may add spacing under images. Outlook.com's webmail has also been shown to support margin when the property name is capitalized (e.g. Margin-left instead of margin-left) — try that before assuming margins are unsupported entirely.
Compound/shorthand CSS (e.g. background: url(...) no-repeat) is unreliable — SendGrid recommends splitting into individual properties like background-image and background-repeat.

How do I fix CSS that isn't rendering in SendGrid?

1. Inline your CSS onto every element. Move styles off classes and into style attributes so nothing depends on a <head> that may be discarded:

<!-- Fragile: depends on <head><style> surviving -->
<td class="cta">Confirm</td>

<!-- Reliable: travels with the element -->
<td style="background-color:#4f46e5;color:#ffffff;padding:12px 20px;font-family:Arial,sans-serif;">Confirm</td>

2. Automate inlining instead of doing it by hand. Author with normal CSS, then run the HTML through an inliner before sending — e.g. the juice library (Node) or premailer (Ruby/Python). This keeps source maintainable while shipping inlined output.

3. Use table-based layout. SendGrid advises building structure with <table>/<tr>/<td>, setting explicit cell widths, and avoiding cellspacing/cellpadding in favor of inline padding where supported.

4. Keep a <style> block only for what can't be inlined. Media queries and pseudo-classes (:hover) can't live in inline styles, so put those in a <head><style> block as a progressive enhancement — and accept that clients which strip the head will fall back to your inline base styles.

5. Verify the class attributes actually survived. If you build in SendGrid's editor, view the saved code or send a test, then inspect the received source to confirm your class/style attributes weren't stripped. Send through the API with pre-inlined HTML if the editor mangles your markup.

6. Test across real clients. Render varies widely; test in Gmail, Outlook desktop, Outlook.com, Apple Mail, and Yahoo (a tool like Email on Acid or Litmus, or simple seed sends, works).

With Courier

If you route SendGrid through Courier, design the template in Courier and let it produce email-safe, inlined HTML, so you avoid hand-maintaining inline styles per element while still delivering via your SendGrid integration.

References

Authoritative sources

DOCSSendGrid Docs (Twilio): Cross-Platform HTML Design DOCSsendgrid/docs Issue #1938: CSS classes stripped when using templates DOCSsendgrid/docs Issue #5487: CSS classes break when email is forwarded

FAQ

Common questions

Browsers render your full HTML document including the <head><style> block. Most email clients (Gmail, Outlook.com, Yahoo) strip the <head> and body tags, discarding embedded <style> rules and any classes that depend on them. Inline the styles directly onto each element so they survive.

Keep going