Why Your Tailwind Email Breaks in Outlook (and How to Inline It Properly)
What inlining really does, where converters fall short, and a workflow that holds up in real inboxes
You build an email in Tailwind. It looks perfect in the browser and fine in Gmail. Then someone opens it in desktop Outlook and the spacing is gone, the button is flat, and the columns have stacked in ways you never designed.
You did nothing wrong for the web. Email just plays by different rules. This post covers why Tailwind struggles in email, what inlining actually does, and a workflow that holds up in real inboxes.
## Why Tailwind and email don't get along
Tailwind classes like `px-6`, `bg-blue-600` and `text-white` don't contain any styling themselves. They point at rules in a stylesheet, which works well when a browser loads that stylesheet.
Email clients give you no such guarantee. Gmail, Outlook, Apple Mail and Yahoo each render HTML with their own engine and support a different slice of CSS. The usual trouble spots are:
- Flexbox and grid in key clients
- Transforms and animations
- Advanced selectors
- `rem` units and CSS variables
- Media queries, which some clients honor and others ignore
The one thing nearly every client respects is a `style` attribute written directly on the element. That's the whole reason email developers inline their CSS.
## What inlining actually does
Inlining takes what a class means and writes it onto the element itself. Here's an illustrative example:
```html
```
The styling now travels with the element, with no stylesheet to load. Doing this by hand across a 200-line template is slow and easy to get wrong, because a single missed declaration can break one section in one client, and you won't see it until a subscriber does.
## The tricky parts
### Responsive variants
Utilities like `sm:` and `md:` rely on media queries, and an inline style can't hold a media query. The practical approach is to inline the static utilities and keep the responsive rules in a `