CSS Inliner for HTML Email
Paste HTML email source with <style> blocks, get back the same HTML with all CSS inlined as style attributes. @media, @keyframes, @supports, and pseudo-class rules are preserved in the original <style> block (those can't be inlined). Specificity, !important, and the cascade are honored. Free, in-browser, no signup.
How to use
- Copy the full HTML source of your email - the same content you'd paste into your ESP's HTML editor or design tool's source view.
- Paste into the input panel above. With auto-inline on, the output appears immediately.
- Verify the output renders correctly - the structure should be identical, but every styled element now has a
styleattribute. - Copy or download the result and use it in your ESP, or run the inbox preview tool to check across Gmail / Apple Mail / Outlook.
What gets inlined and what doesn't
- Inlined: all unconditional class / id / element / attribute selectors that don't contain pseudo-classes or pseudo-elements.
- Preserved (kept in
<style>):@mediaqueries,@supportsblocks,@keyframesand@font-facedeclarations,@importstatements, and any rule whose selector contains:hover,:focus,:active,:first-child,::before,::after, etc. - Existing inline styles: kept. They only get overridden by an
!importantrule from a<style>block. - Specificity: when two rules target the same property on the same element, the higher-specificity rule wins.
!importantalways wins. Source order breaks ties.
FAQ
Why does email need inline CSS?
Most email clients strip or partially strip <style> blocks at the head of an email. Gmail's web interface keeps them, but Gmail's mobile apps don't. Outlook desktop honors only some properties from <style> and ignores others entirely. Yahoo, AOL, and several mobile clients ignore <style> blocks completely. Inline styles are the only CSS form supported by every email client without exception.
What does this tool actually do?
It parses your HTML, finds every CSS rule in <style> blocks, computes which elements each rule matches, and writes the matching declarations as style attributes on each element - respecting CSS specificity, !important, and the cascade. After inlining, the original <style> blocks are reduced to only the rules that can't be inlined: @media, @supports, @keyframes, and pseudo-class rules.
Why preserve @media queries instead of flattening?
@media queries are how you make email responsive. They live in <style> blocks because there's no way to express "apply this style only on screens narrower than 600px" as an inline attribute. Apple Mail, Gmail web, and modern Android Gmail honor @media queries inside <head> <style> blocks. Inlining the rule once would break the conditional behavior.
How are pseudo-classes like :hover handled?
They can't be inlined - inline styles have no concept of state. If you write a:hover { color: red } and we tried to inline it, every link would just be red permanently. Pseudo-class rules are kept as-is in the <style> block. Clients that support hover (Apple Mail, Gmail web, Yahoo) will honor them; clients that don't (Outlook desktop) will ignore the styled state.
How does specificity work in the inliner?
Standard CSS rules apply: when two rules target the same property on the same element, the higher-specificity selector wins. The inliner counts IDs, classes/attributes/pseudo-classes, and element types per selector, and for each property writes the winning declaration's value as inline. !important wins over non-important. Source order breaks ties.
Does my HTML get sent anywhere?
No. Everything happens in your browser. The inliner uses a hidden iframe to parse your HTML and access the browser's native CSS engine, then writes the result back into the output panel. Zero outbound requests.
What's the Gmail 102 KB clip threshold?
Gmail clips emails larger than 102 KB and shows a "View entire message" link. The clip can hide tracking pixels and unsubscribe links. Inlining tends to grow file size because the same rule may be repeated as inline styles across many elements. The output size card flags any output above 102 KB.
Why use a hosted inliner instead of build-time tools?
If you have a build pipeline, juice / mjml / litmus all inline at build - use those, they're more accurate. This tool exists for the cases where you don't: pasted ESP exports, hand-written test emails, designs from a no-code tool, last-minute fixes during a campaign.
Send the email this output is for
MiN8T's editor inlines CSS automatically on export and ships HTML that's already Outlook-safe. Skip the manual inline step.
Open MiN8T Editor →