Tailwind to WordPress Theme: Where Classes Go

Why the classes do not come along

Lovable styles your app with Tailwind CSS and shadcn/ui. A card is a div with a dozen utility classes on it. The browser reads those classes from a stylesheet that Tailwind generates at build time.

A WordPress block theme works the other way around. Design values live in theme.json, which WordPress turns into CSS variables and preset classes. Content lives in block markup, where each block carries its own attributes: a color slug, a font size, padding values. The Site Editor reads and writes those attributes.

So a converted theme has to translate, not copy. You could paste a Tailwind build into a block theme and keep the class names, but then nothing would be editable in WordPress. Change a color in the Site Editor and the utility class would still win. A theme that behaves like a WordPress theme has to put the values where WordPress looks for them.

What Tailwind utilities become in a block theme

Most of a Tailwind design system is a scale: a palette, a type scale, a spacing scale. Those are exactly the things theme.json is built to hold. The rest is layout, and WordPress has blocks for it.

Here is the rough mapping we use when converting a Lovable project.

• Colors — bg-primary, text-muted-foreground and the rest of the Tailwind and shadcn palette become named entries in theme.json. Blocks then reference a color slug instead of a class.
• Type scale — text-sm through text-5xl become font size presets. Headings and paragraphs get the matching preset.
• Fonts — Google Fonts used by the project are registered in theme.json as font families, so the Site Editor offers them.
• Spacing — p-8, gap-6, mt-16 become padding, margin and block gap values on the blocks that need them.
• Layout — flex rows and grid columns become Columns blocks. A max-w-6xl mx-auto wrapper becomes a constrained Group with a content width.
• Borders and radius — rounded-xl, border and shadow utilities become block border and shadow settings where a block supports them.

What has no WordPress equivalent

Some utilities describe behavior rather than design. WordPress blocks have no place to put them, so they are approximated or dropped. Being clear about this up front saves a lot of confused comparison.

Responsive prefixes are the biggest difference. Tailwind lets you say grid-cols-1 md:grid-cols-3. A Columns block has one set of columns, and WordPress stacks them on mobile. Converted layouts therefore use the desktop values, and the mobile result is a stack. That is usually fine for marketing pages and wrong for anything that changes structure at a breakpoint.

State and interaction utilities are the other gap. Hover colors on buttons and links do carry over, because block themes support hover styles. But group-hover:, peer-checked:, data-[state=open]: and anything driven by React state do not. Tabs, modals and dropdowns convert in their default state only. Animations land on their final state.

Absolutely positioned decorations — blurred gradient blobs, offset rings, -z-10 shapes — are left out. So are canvas, Lottie and iframe elements. They are not block markup and there is no honest way to approximate them.

What the converted theme actually contains

The IQDesk converter turns a Lovable ZIP or GitHub repository into a block theme in the browser. The Tailwind translation above is what it does with your styles.

The output is a normal WordPress block theme. theme.json holds the palette, the font families and the type and spacing scales. templates/ holds the page templates, parts/ holds the header and footer, and patterns/ holds one pattern per page from your app. Images are copied into the theme folder. There is no Tailwind build step, no tailwind.config.ts, and no utility stylesheet to maintain.

Install it the usual way: Appearance → Themes → Add New → Upload Theme → Activate. Pages are created on activation and the front page is set. From there every value we moved into theme.json is editable at Appearance → Editor, which is the point of the translation.

The review screen shows the converted site next to the original inside WordPress Playground, so you can see which Tailwind details survived before you download anything. Conversion, review and download are free. For a full list of what converts, is approximated and is left out, see supported features.

Checking the translation after install

Tailwind-heavy pages are worth a close read after activation. Work from the design tokens outward, not element by element.

A short pass that catches most issues:

1. Open the Site Editor at Appearance → Editor and check the palette under Styles. Every brand color from your Tailwind config should be there with a readable name.
2. Check the type scale. Compare an h1, an h2 and body text against the original. If a heading is a step too small, change the font size preset once instead of editing each page.
3. Look at section spacing. Tailwind sections often use large vertical padding. If sections feel tight, adjust the Group padding in the pattern rather than adding spacers.
4. Resize the browser. Confirm the mobile stacking is acceptable on every grid. This is where desktop-only conversion shows.
5. Hover every button and link. Hover colors convert; more complex group states do not, so decide if the plain state is good enough.
6. Scan for missing decoration. Blobs, rings and animated backgrounds will be gone. Replace them with a background color, a gradient or a real image.

Keeping a Tailwind look without Tailwind

Once the tokens are in theme.json, the site keeps the Tailwind feel because the feel comes from the values: a tight neutral palette, a generous type scale, consistent radius, lots of whitespace. None of that needs utility classes.

If you want to keep editing in WordPress, resist the urge to re-add Tailwind. A block theme with a utility stylesheet on top is two systems fighting over the same elements, and the Site Editor loses. Edit the presets instead; they cascade across every page.

If a specific section truly needs CSS that blocks cannot express — a positioned decoration, a sticky sidebar effect — add it as a small block of custom CSS in the Site Editor under Styles, scoped to a class you add to that block. That keeps the exception visible and local.

If you would rather stay on React and Tailwind as they are, that is a valid answer too. Lovable hosting serves the built app directly, and so does any static host. Our Lovable vs WordPress comparison walks through the trade-off, and Lovable hosting covers staying put.

FAQ

Can I use Tailwind CSS inside a WordPress block theme?

You can, but it works against the Site Editor. WordPress expects design values in theme.json so editors can change them, while Tailwind utility classes are fixed in the markup. A converted block theme moves the Tailwind values into theme.json instead, which keeps the same look and makes it editable in WordPress.

Do my Tailwind colors and fonts survive the conversion?

Yes. The palette, the type scale, spacing values and any Google Fonts the project uses are written into theme.json as named presets. After activating the theme you can see and edit all of them under Appearance then Editor, in Styles.

What happens to responsive classes like md:grid-cols-3?

The desktop value is used. A Tailwind grid becomes a Columns block with that number of columns, and WordPress stacks those columns on mobile by default. Layouts that change structure at a breakpoint need a manual adjustment after conversion.

Are hover and animation classes converted?

Hover colors on buttons and links are converted, because block themes support hover styles. Group hover, state-driven variants and JavaScript interactions are not. Animations are rendered in their final state, so the element appears as it looks after the animation ends.

Will the converted theme need a build step?

No. The output is a plain WordPress block theme made of HTML templates, patterns, theme.json and image files. There is no Tailwind config, no npm install and no compile step, so you can upload the ZIP under Appearance then Themes and activate it.

Keep reading