Add to Chrome — first conversion freeWhy this conversion is different
Tailwind's output is purged and minified, which usually scares people converting a site: the class names look meaningless out of context. That does not matter here, because the conversion keeps both the markup and the stylesheet that gives those classes meaning.
Anything defined in your theme layer — custom colour scales, font families, spacing steps, container queries, plugin utilities — is already compiled into the CSS by the time the browser paints. Capturing the painted result means none of that configuration has to be recreated in WordPress.
Watch out for two Tailwind-specific traps: a dev build ships the full unpurged stylesheet, and dark mode depends on a class or media query state. Capture a production build, in the colour scheme you want to ship.
How it works, step by step
1. Build for production
Run your production build so Tailwind purges unused utilities and the stylesheet is minified. Serve that build, or use your deployed URL — never the dev server.
2. Pick the colour scheme and capture
Set light or dark mode to the state you want as the theme default, scroll through so intersection-observer animations have fired, then click Generate theme.
3. Install in WordPress
Upload the .zip under Appearance → Themes → Add New → Upload Theme and activate. The compiled Tailwind CSS ships inside the theme, so no build step is needed on the WordPress side.
What gets converted — and what doesn't
Converted
- Every applied utility class and its compiled declaration
- Custom theme tokens: colours, fonts, spacing, radii, shadows
- Responsive prefixes (sm:, md:, lg:, xl:, 2xl:) and their media queries
- Dark-mode variants as rendered in the captured state
- Arbitrary values such as w-[38.5%] and bg-[#0f172a]
- Plugin output: typography, forms and container utilities
Not converted
- The Tailwind build pipeline itself — the theme ships compiled CSS, not a config
- Class toggling done by JavaScript at runtime (only the captured state ships)
- Both colour schemes at once from a single capture
- Data fetched client-side after page load
A real example
Before
A Next.js + Tailwind marketing site with a gradient hero, a bento feature grid, a dark-mode toggle and scroll-reveal sections.
After
A WordPress theme with the gradient, the bento grid and the reveal styling intact in the chosen colour scheme, with the compiled stylesheet and fonts bundled in /assets.
The production build is opened, dark mode is left on, the page is scrolled to trigger every reveal, and the capture stores the final painted state.
Benefits
- No Tailwind config to port and no build step inside WordPress
- Design tokens stay exact instead of being eyeballed into new CSS
- Works whatever renders the Tailwind markup: React, Vue, Astro, plain HTML
- Free first conversion to check fidelity on your own site
Limits to know before you start
- One capture equals one theme state — dark and light need separate captures
- JS-driven interactivity ships as styled markup, not behaviour
- Unpurged dev builds produce needlessly large stylesheets, so always build first
Frequently asked questions
Does Tailwind CSS survive a WordPress conversion?
Yes. Tailwind compiles to standard CSS before the browser paints, and the conversion reads the applied styles, so utilities and custom tokens render identically inside WordPress.
Do I need Tailwind installed on the WordPress site?
No. The generated theme contains the already-compiled stylesheet, so there is no Node build step on the WordPress side.
What about dark mode?
The capture stores whichever scheme was active. Convert twice if you want both, or re-add the toggle in the generated theme.
Will arbitrary values and custom plugins carry over?
Yes — they are ordinary CSS declarations by the time the page renders, so they are captured like any other rule.