CSS in Email: What You Can and Cannot Do
The practical reality of styling HTML emails with CSS.
TL;DR: CSS in Email - What You Actually Need to Know
CSS in email is fundamentally different from web development. Unlike modern browsers that support Flexbox, Grid, and sophisticated styling, email clients use inconsistent rendering engines. Outlook uses Microsoft Word's engine, Gmail strips many CSS properties, and Apple Mail supports modern CSS. This fragmentation means you must use tables for layout, inline styles for reliability, and avoid modern CSS properties that don't work across clients.
The key principles: Use inline styles as your primary styling method (they work everywhere), employ tables for layout structure (divs and spans are unreliable), stick to safe CSS properties (color, font-size, padding on table-cells), and avoid positioning (absolute/relative/fixed don't work reliably). Background images require VML for Outlook support, media queries work in some clients but not others, and web fonts have limited support. Always test in Outlook first - if it works there, it probably works everywhere. For developers who want to bypass these complexities entirely, HTML email builders like Sequenzy automatically generate compatible code, letting you focus on design rather than debugging rendering issues across 90+ email clients.
Best practices: Start with a CSS reset for email, use both inline and embedded styles (inline for critical rendering, embedded for media queries), leverage CSS inliner tools to automate the conversion process, and test across major clients (Gmail, Outlook, Apple Mail, Yahoo). Never rely on floats or CSS positioning for layout - tables are still the safest approach in 2026. For teams building SaaS products or marketing campaigns, visual email builders with drag-and-drop interfaces eliminate the need to hand-code email HTML while ensuring cross-client compatibility.
CSS in email is a constrained subset of CSS in browsers. Properties you use daily in web development may not work in email clients. This guide documents what is safe, what requires workarounds, and what to avoid entirely.
If you want to skip the CSS limitations, visual builders like Sequenzy generate compatible code automatically. But understanding CSS in email helps you debug issues and make informed decisions.
What Are CSS Email Limitations?
CSS email limitations exist because email clients use different rendering engines. Unlike web browsers that have largely standardized on modern engines (WebKit, Blink, Gecko), email clients use fragmented technology:
- Outlook (Windows): Uses Microsoft Word's rendering engine - the most restrictive client
- Gmail: Strips style tags and many CSS properties for security
- Apple Mail: Uses WebKit (Safari's engine) - supports modern CSS
- Mobile clients: Varying levels of CSS support
This means CSS that works perfectly in your browser may break entirely in email. Flexbox and Grid do not work in email. CSS positioning (absolute, relative, fixed) is unreliable. Floats fail in Outlook. The only safe layout approach is tables.
HTML email builders solve this problem by generating compatible code automatically. When you drag a button into a Sequenzy email template, the platform outputs the table-based HTML with inline styles that work across all clients. You get modern visual editing while maintaining compatibility.
How Email CSS Works: The Technical Reality
Email CSS works through a combination of inline styles, embedded styles, and conditional code. Here's the hierarchy:
- Inline styles (most reliable) - Applied directly to elements via the style attribute
- Embedded styles (moderate reliability) - CSS in style tags within the email head
- Conditional comments (Outlook-specific) - Special code that only Outlook reads
Smart email developers and drag-and-drop email builders use all three approaches strategically. Inline styles handle critical rendering that must work everywhere. Embedded styles provide responsive enhancements via media queries. Conditional comments fix Outlook-specific issues like background images.
Comparison: CSS Support Across Email Builders
| Email Builder | CSS Handling | Media Queries | Price |
|---|---|---|---|
| Sequenzy | Automatic inlining, VML for Outlook, dark mode support | Built-in responsive templates with media queries | $19/mo, free trial |
| MJML | Framework compiles to email-safe HTML with inline CSS | Automatic responsive stacking | Free open-source |
| Stripo | Drag-and-drop with automatic CSS inlining | Custom media query support | $15/mo and up |
| BEE Free | Visual builder with inline style generation | Mobile-responsive templates | $25/mo and up |
| React Email | Code-based with automatic CSS inlining | Manual media query implementation | Free open-source |
Inline vs Embedded Styles
Inline Styles (Most Reliable)
<p style="color: #333333; font-size: 16px; line-height: 1.5;">
Text with inline styles
</p>Inline styles work in all email clients. They have the highest specificity and cannot be stripped. The downside: verbose code and no reuse without duplication.
Embedded Styles (Head)
<head>
<style>
.text-body {
color: #333333;
font-size: 16px;
line-height: 1.5;
}
</style>
</head>
<body>
<p class="text-body">Text with class</p>
</body>Embedded styles work in most clients but Gmail has historically stripped them in certain contexts. Use for enhancements (media queries) but not for critical styles.
Best Practice: Both
Use inline styles for critical rendering. Use embedded styles for media queries and progressive enhancement. CSS inliner tools automate this conversion.
Typography CSS
Safe Font Properties
font-family: Arial, Helvetica, sans-serif;
font-size: 16px;
font-weight: bold; /* or 700 */
font-style: italic;
color: #333333;
line-height: 1.5; /* or 24px */
text-align: left; /* center, right */
text-decoration: none; /* underline */
text-transform: uppercase; /* lowercase */
letter-spacing: 1px;All major clients support these properties. Stick to px units for font-size (em/rem less reliable). Avoid font-weight values other than normal (400) and bold (700).
Web Fonts
<style>
@import url('https://fonts.googleapis.com/css2?family=Roboto&display=swap');
</style>
<p style="font-family: 'Roboto', Arial, sans-serif;">
Custom font with fallback
</p>Web fonts work in Apple Mail, iOS, and some Android clients. Gmail and Outlook use the fallback. Always include a web-safe fallback.
Box Model CSS
Padding (Safe on Table Cells)
<td style="padding: 20px;">
Content with padding
</td>
<!-- Or individual sides -->
<td style="padding-top: 20px; padding-bottom: 10px;">
Content
</td>Padding on table cells is reliable. On divs and paragraphs, results vary. When in doubt, use table cells.
Margin (Use Carefully)
Margins are inconsistent, especially in Outlook. Prefer padding on container cells over margins on content.
<!-- Instead of margin on heading -->
<td style="padding-bottom: 20px;">
<h1 style="margin: 0;">Heading</h1>
</td>Width and Height
width: 600px;
width: 100%;
max-width: 600px;
height: 200px; /* Avoid when possible */Width works reliably. max-width is useful for responsive emails but Outlook ignores it (use conditional comments for Outlook fixed width). Height should be avoided since content should determine height.
Background CSS
Background Color (Safe)
background-color: #f5f5f5;
background: #f5f5f5; /* shorthand works too */Background Images (Complex)
<!-- Works in most clients, NOT Outlook -->
<td style="background-image: url('image.jpg'); background-color: #333;">
<!-- For Outlook, use VML -->
<!--[if gte mso 9]>
<v:rect style="width:600px;height:300px;" stroke="false" fill="true">
<v:fill type="tile" src="image.jpg" />
<v:textbox>
<![endif]-->
<div style="background-image: url('image.jpg');">
Content
</div>
<!--[if gte mso 9]>
</v:textbox>
</v:rect>
<![endif]-->Background images require VML for Outlook support. Always include a background-color fallback.
Border CSS
Solid Borders (Safe)
border: 1px solid #cccccc;
border-bottom: 2px solid #333333;
border-top: none;Border Radius (No Outlook)
border-radius: 4px; /* Ignored in Outlook */Border-radius works in most clients but Outlook shows square corners. For buttons, this is usually acceptable. For critical rounded designs, use images.
Layout CSS
Display Property
display: block;
display: inline;
display: inline-block;
display: none;Basic display values work. display: flex and display: grid do NOT work in email. Use tables for layout.
Position (Avoid)
CSS positioning (absolute, relative, fixed) does not work reliably. Use table-based layout instead.
Float (Avoid)
Floats are unreliable in Outlook. Use table columns for side-by-side content.
Media Queries
@media screen and (max-width: 600px) {
.mobile-full {
width: 100% !important;
display: block !important;
}
.mobile-hide {
display: none !important;
}
.mobile-text-center {
text-align: center !important;
}
}
@media (prefers-color-scheme: dark) {
.dark-bg {
background-color: #1a1a1a !important;
}
}Media queries work in Apple Mail, iOS, Gmail App. They do NOT work in Outlook or Gmail web (reliably). Use !important to override inline styles.
CSS Reset for Email
<style>
/* Prevent text size adjustment */
body, table, td, p, a, li {
-webkit-text-size-adjust: 100%;
-ms-text-size-adjust: 100%;
}
/* Remove table spacing */
table, td {
border-collapse: collapse;
mso-table-lspace: 0pt;
mso-table-rspace: 0pt;
}
/* Remove image borders and gaps */
img {
-ms-interpolation-mode: bicubic;
border: 0;
display: block;
outline: none;
text-decoration: none;
}
/* Reset body */
body {
margin: 0;
padding: 0;
width: 100% !important;
height: 100% !important;
}
</style>CSS Inlining
Tools convert embedded styles to inline styles for reliability:
- Juice: Node.js library for CSS inlining
- Premailer: Online tool and gem
- MJML: Handles inlining during compilation
- Email builders: Sequenzy and others inline automatically
Debugging CSS Issues
- Check inline styles first. Missing or incorrect inline styles are the most common issue.
- Test in Outlook. If CSS works in Outlook, it probably works everywhere.
- Simplify. Remove CSS until the issue disappears, then add back gradually.
- Check specificity. Inline styles may override your embedded styles.
Best Practices for CSS in Email
1. Use Tables for Layout Structure
Tables remain the most reliable layout method in email. While web development moved away from tables years ago, email HTML requires them for cross-client compatibility. Use nested tables for complex layouts, with table cells acting as divs. All modern HTML email builders generate table-based structures automatically.
2. Inline Critical Styles
Any style that affects the core appearance of your email should be inline. This includes colors, fonts, spacing, and sizing. Use CSS inliner tools or let your email platform handle this automatically. Sequenzy and other visual builders inline styles during export, ensuring Gmail doesn't strip your critical CSS.
3. Test Across Clients Early
Don't wait until deployment to test. Use tools like Litmus or Email on Acid to preview your email in 90+ clients. Focus on Outlook (Windows), Gmail (web and mobile), and Apple Mail. If it works in these three, it likely works everywhere.
4. Embrace the Constraints
Email CSS is what it is. Instead of fighting against the limitations, use them to your advantage. Simple, table-based layouts load faster, are more accessible, and often look more professional than overly complex designs. No-code email builders help you work within constraints while still creating beautiful designs.
Frequently Asked Questions
Can I use Flexbox or Grid in email?
No. Flexbox and Grid do not work reliably in email clients. Use tables for layout instead. Some modern email frameworks simulate Flexbox-like behavior using tables and conditional comments, but actual CSS Flexbox is not supported.
Do I need to write inline styles manually?
No. Use CSS inliner tools like Juice or Premailer to automate this. Or better yet, use visual email builders like Sequenzy that generate inline styles automatically. You design visually, and the platform handles the technical output.
Why doesn't Gmail support my embedded CSS?
Gmail strips style tags and many CSS properties for security reasons. This is why inline styles are essential. Some embedded styles work in Gmail's mobile apps, but web Gmail is very restrictive. Always inline critical styles.
What's the difference between email builders and frameworks?
HTML email builders (like Sequenzy, Stripo, BEE) provide visual drag-and-drop interfaces. Email frameworks (like MJML, React Email) require coding but generate compatible HTML. Both approaches solve the CSS compatibility problem - choose based on whether you prefer visual editing or writing code.
How do I handle responsive design without media queries?
Use fluid layouts with percentage-based widths and max-width constraints. This works in all clients without media queries. For enhanced mobile experiences, add media queries that clients like Apple Mail will respect while falling back gracefully in Outlook.
Should I learn email HTML or use a builder?
For most teams, visual email builders are the better choice in 2026. They handle CSS compatibility automatically, integrate with sending platforms, and let non-developers create emails. Learn email HTML only if you have specific customization needs that builders can't handle.
The Bottom Line
CSS in email is a constrained language. Stick to well-supported properties, use inline styles for critical rendering, and test across clients. Frameworks and builders like Sequenzy handle these constraints automatically.
The limitations are frustrating if you are used to modern web CSS. But understanding them lets you build emails that render consistently across all the quirky email clients your recipients use. For teams who want to bypass the complexity entirely, modern HTML email builders provide drag-and-drop interfaces that generate compatible code while letting you focus on design and content rather than debugging Outlook rendering issues.