Why email needs inline CSS
A web page keeps its CSS in one tidy style block or an external file, and every browser respects it. Email is not so kind. Desktop Outlook renders messages with Word's HTML engine, which ignores or mangles a large slice of embedded CSS. Some webmail clients rebuild the message and throw away the head, taking any style block with it, and forwarding a message often does the same. The one place a style reliably survives is on the element itself, in a style attribute, because it travels wherever the element goes. That is why almost every professionally sent marketing email you receive has its CSS inlined, and why most email platforms inline styles as a build step.
This tool does that step for you. Paste your template, press Convert, and every rule from your style blocks is copied onto the elements it matches. Everything happens in your browser: your templates, copy and links are never uploaded anywhere.
How the conversion works
Your HTML is parsed with the browser's own parser, then each CSS rule is applied to its matching elements in source order, so a later rule overrides an earlier one for the same property, just as the cascade would. Anything already written in an inline style attribute always wins, because inline styles beat style blocks in real CSS too. The style blocks are then removed and the document serialised back.
What cannot be inlined
An inline style is unconditional, so anything that depends on state or context has no inline equivalent. Pseudo-classes and pseudo-elements such as a:hover or .btn::after are skipped, and the report under the output lists every skipped selector so nothing disappears silently. Media queries cannot be inlined either, but they matter for responsive email, so by default they are kept in a small retained style block. Modern clients such as Apple Mail, Gmail and Outlook.com respect that block, while clients that strip it simply fall back to your inlined base styles. The practical recipe: make the inlined styles your single-column, mobile-friendly baseline, and treat the media queries as progressive enhancement for the clients that keep them.
At-rules like @font-face and @keyframes are also skipped and reported. Web fonts work in only a minority of clients anyway, so always specify fallback system fonts in your font-family stacks.
Keeping Gmail from clipping your message
Gmail clips any message whose HTML exceeds 102 KB, hiding the rest behind a "View entire message" link, which can bury your unsubscribe link and hurt engagement. Inlining adds weight because shared rules are repeated on every matching element, so trim what you can. The strip-classes option removes class attributes after inlining, which claws back a useful chunk on class-heavy templates; leave it off if your retained media queries or your sending platform still need those classes. Keep the retained style block lean, cut unused rules before converting, and consider running the CSS through a minifier first. Test the finished template in the clients your audience actually uses, because the only rendering that matters is theirs.
Frequently asked questions
Why do email templates need inline CSS?
Email clients are far less predictable than browsers. Desktop Outlook renders HTML with Word's engine and ignores much embedded CSS, some webmail clients strip the head of a message along with any style blocks, and forwarding often does the same. A style written directly on the element in a style attribute travels with the element, so it survives almost everywhere.
Is my HTML uploaded anywhere?
No. Parsing, matching and rewriting all happen in your browser with JavaScript. Your templates, copy and links never leave your device, so it is safe to use with unreleased campaigns and client work.
What happens to hover styles and media queries?
They cannot be expressed as inline styles, so they are never inlined. Media queries are kept in a small retained style block by default, which modern clients such as Apple Mail and Gmail respect. Pseudo-class and pseudo-element rules like a:hover or .btn::after are skipped and listed in the report so you know exactly what was left out.
Does the converter change my HTML structure?
The document is parsed with your browser's own HTML parser, styles are applied, and the result is serialised back. Elements, attributes, text and order are preserved, though minor normalisation can occur, for example attribute quoting or the repair of unclosed tags, exactly as a browser would repair them.
Should I strip class attributes after inlining?
Once every rule is inlined the classes usually do nothing, and removing them shrinks the message, which helps you stay under Gmail's clipping limit. Keep them if your retained media queries still target those classes, or if your sending platform uses them for link tracking or editing.