Tailwind CSS to WordPress: Converting a Tailwind HTML Site to a Working Theme

Tailwind CSS sites look sharp in a browser. But your client runs WordPress, and nobody wants to rebuild the whole design from scratch. Here's how Tailwind HTML actually transfers to WordPress, what the build process does to your CSS, and the fastest way to get a working theme without touching webpack.

Why Tailwind sites need WordPress

Tailwind is the default CSS framework for a huge chunk of modern web development. You use it in vite projects, in Laravel, in Next.js, in plain HTML files. The design comes out polished. Then the client asks for WordPress.

The reasons are predictable. The client already runs other sites on WordPress. They want WooCommerce for selling. Their team knows how to edit content in Gutenberg. They need ACF fields or Yoast SEO. Whatever the reason, you have a Tailwind-based design and you need it running on WordPress.

This is not the same as converting a raw HTML file. Tailwind has a build step that changes what CSS actually ships. That build step is the thing you need to understand before picking your approach.

The Tailwind CSS build problem

In development, Tailwind scans your HTML files and generates only the utility classes you actually use. This is called purging or content scanning, depending on which Tailwind version you're on. The resulting CSS file is small and clean. It's not the full Tailwind library.

Here's why that matters for WordPress conversion.

• The class names are not CSS. text-blue-600, px-4, rounded-lg are meaningless without the Tailwind stylesheet that maps them to properties. Copy the HTML without the CSS and you get unstyled content.
• The stylesheet is a build artifact. You don't write the CSS by hand. It's generated by the Tailwind CLI or a PostCSS plugin when you build your project.
• JIT mode generates classes on the fly. Tailwind v3 and v4 use just-in-time compilation. The CSS exists in the browser during development via a dev server, but it's not a static file until you run a production build.

The good news: once you've run a production build, the output is a standard CSS file. At that point, the Tailwind connection is severed. You have HTML and CSS. The WordPress problem is a normal HTML to WordPress theme conversion.

Three approaches

Manually build Tailwind into WordPress

Add Tailwind CSS directly into your WordPress theme development workflow. Install Node, add Tailwind as a dev dependency, configure it to scan your PHP template files, and add a build script to your theme.

This is the "proper" developer way. Your WordPress theme becomes a Tailwind project. You edit PHP templates with Tailwind classes, run npm run build, and the theme CSS updates.

Time: 8-20 hours minimum. You're rebuilding the design in PHP templates, not converting the existing HTML. Every section needs to become a WordPress template. You need to know both Tailwind and WordPress theme structure. For a simple site, this works. For anything complex, it's a full rebuild disguised as a migration.

Extract the production CSS and manually assemble templates

Run your Tailwind production build. Copy the generated CSS file. Then manually write WordPress PHP templates that use those same Tailwind classes.

Time: 4-10 hours. You still need to translate HTML into PHP template files. You need to add WordPress functions: wp_head(), wp_footer(), body_class(), the loop. You need to set up a valid theme folder structure with style.css, functions.php, and template hierarchy files.

If your Tailwind site is deployed somewhere publicly accessible, there's a better way.

URL capture via StaticToWP

If your Tailwind site is deployed to any public URL, the conversion takes about 60 seconds. StaticToWP renders your page in a real browser, captures the fully computed HTML and CSS, bundles all assets, and generates a complete WordPress theme zip.

The browser does the Tailwind build work for you. By the time the page is fully rendered, all those utility classes have been resolved to computed CSS properties. The theme captures those properties. No Tailwind CLI needed. No Node. No build step to replicate.

This is the same approach that handles Webflow to WordPress and Framer to WordPress. The live URL is the source of truth. Not the source code.

What Tailwind CSS does to your output

Understanding what the browser sees helps you predict what transfers cleanly.

Tailwind utility classes compile to standard CSS rules. text-blue-600 becomes color: rgb(37, 99, 235). px-4 becomes padding-left: 1rem; padding-right: 1rem. By the time the browser has rendered your page, every Tailwind class has been resolved to its underlying property values.

When you capture that rendered output, you capture the computed CSS. Your WordPress theme doesn't need to know anything about Tailwind. It just needs the CSS that Tailwind produced.

Step-by-step: Tailwind site to WordPress

1. Deploy your Tailwind site to a public URL. Vercel, Netlify, GitHub Pages, or any public host works. If you're on localhost, deploy a preview first. The URL needs to be publicly accessible with no login required.
2. Paste the URL into StaticToWP. Go to StaticToWP and enter your site URL. The tool renders the page, resolves all Tailwind classes, and captures the result.
3. Download the theme zip. You get a wp-theme.zip in about 60 seconds. It contains all WordPress template files, your CSS, bundled fonts, and any local JavaScript.
4. Upload to WordPress. Go to Appearance → Themes → Add New → Upload Theme, upload the zip, and activate it.
5. Set your homepage. In Settings → Reading, set homepage display to "A static page" and choose your front page.
6. Check responsive behavior. Tailwind breakpoints (sm:, md:, lg:) are media queries. They transfer verbatim and work in WordPress without changes.

What transfers and what doesn't

What transfers cleanly

• All Tailwind utility CSS. Every class resolves to standard CSS in the browser. Typography, colors, spacing, flexbox, grid — all captured.
• Responsive breakpoints. Tailwind media queries are standard @media rules. They carry over without changes.
• Dark mode (CSS class strategy). If you use Tailwind's class dark mode strategy, the dark mode CSS transfers. You'll need a toggle script in the theme to switch the dark class on html, but the styles are there.
• Custom Tailwind config values. Custom colors, fonts, spacing scale — these compile into the CSS output. Your specific brand values survive.
• Animations. Tailwind's built-in animations (animate-spin, animate-pulse, animate-bounce) are keyframe rules captured in the CSS.
• Google Fonts and local fonts. Font URLs carry over. Custom fonts loaded from /public get bundled into the theme's assets folder.

What needs work after migration

• Tailwind CSS CDN (Play CDN / v4 browser build). If you're using Tailwind's browser CDN for prototyping, the CSS is injected dynamically at runtime. It doesn't exist as a stylesheet until the page fully loads. StaticToWP captures the rendered output, so this generally works, but some dynamic class generation may be missed. For production sites, use a build step before converting.
• Tailwind plugins that require JavaScript. Typography plugin (@tailwindcss/typography) is pure CSS and transfers fine. Plugins that add JavaScript interactivity need their JS captured separately.
• Dark mode with media strategy. If you use prefers-color-scheme media query dark mode, it works in WordPress automatically. No additional setup needed.
• Dynamic class generation. If your code generates Tailwind classes programmatically at runtime (e.g., template literals like text-blue-600 built from variables), PurgeCSS may have removed those classes from your production CSS. If they were not in the rendered output at capture time, they will not be in the theme.

Tailwind CSS via CDN vs. production build

If your Tailwind site uses the Play CDN for quick prototyping, the CSS is generated in the browser via a Web Worker. When the page is captured, that generated CSS is in the <style> tags of the rendered HTML.

This works for most sites. If you're doing advanced Tailwind features like @apply with custom directives, or if you're generating classes based on server-side data, run a production build first and deploy that instead. The production CSS file is more predictable.

After migration: making it editable

The generated WordPress theme includes ACF-compatible field structure for editable text and images. Your client can update content through the WordPress admin without touching the Tailwind classes.

For teams that want to keep Tailwind in the WordPress workflow long-term, consider the manual integration approach after the initial migration. Use StaticToWP to get the design into WordPress first, then incrementally move to a Tailwind-in-PHP setup for sections that need frequent updates.

FAQ

Do I need Node.js or npm to convert a Tailwind site to WordPress?

No. If you use the URL capture method, StaticToWP handles everything in a headless browser. You don't need to run Tailwind locally. Deploy your site first, paste the URL, download the theme zip. No Node required on your machine for the conversion step.

Will my Tailwind CSS file be included in the WordPress theme?

The converted theme includes the CSS in the form it existed in the browser at capture time. If Tailwind was compiled to a production stylesheet, that stylesheet is bundled. If the CDN version was used, the captured inline styles are bundled. Either way, the theme is self-contained. It doesn't need Tailwind installed to work.

My Tailwind site has multiple pages. Can I convert all of them?

StaticToWP converts one URL at a time. For a multi-page site, convert each page separately and combine the templates. Or convert your main page and add additional pages through WordPress's page editor, styling them to match using the captured theme's CSS.

What about Tailwind v4?

Tailwind v4 uses a different build system (Vite-first, no PostCSS config by default) but the output is the same: standard CSS. Once your v4 site is deployed and rendering in a browser, the capture process is identical. The CSS it produces is just as capturable as v3.

My site uses shadcn/ui components on top of Tailwind. Will those work?

shadcn/ui components are built with Radix UI primitives and styled with Tailwind. The CSS transfers cleanly. The JavaScript-driven behavior (dropdowns, dialogs, tooltips, toggles) is also captured if it was rendered and initialized in the browser at capture time. Radix primitives that need client-side mounting to display their content may need manual JS activation after conversion.