shadcn/ui to WordPress: How Components Map

Why shadcn/ui needs a mapping at all

Lovable builds React and TypeScript apps styled with Tailwind CSS, and most of the visible UI comes from shadcn/ui. shadcn/ui is not a script you load. It copies component source files into your project, usually under src/components/ui, so a Card or an Accordion is plain React in your own repository.

WordPress renders HTML from block markup stored in post content and template files. There is no React runtime on the front end of a block theme. So a conversion cannot keep the component; it has to keep the result the component produced.

That is the useful way to think about it. For every shadcn/ui component, ask what HTML it renders and whether that HTML holds content or behavior. Content survives. Behavior does not, unless a plugin supplies it.

The components that map cleanly

These shadcn/ui components are containers around text, images and links. They have a one-to-one or near one-to-one equivalent in core WordPress blocks, and the result is editable in the Site Editor like any other block.

Our converter produces this mapping automatically, but the table is the same if you rebuild by hand.

Card → a Group or Column with a rounded border, an Image block, a Heading and a Paragraph. CardHeader, CardContent and CardFooter become the blocks inside, in order.
Button → the Buttons block. Variants become button styles; hover colors move into theme.json.
Accordion → the Details block, which is core WordPress and needs no JavaScript.
Separator → the Separator block.
Avatar → an Image block with a round border radius.
Badge → a short inline element inside a paragraph, styled with the palette color it used in Tailwind.
Table → the Table block.
Blockquote and lists → the Quote block and the List block.
Navigation menu in a header → the Navigation block inside a header template part.
Aspect ratio wrappers → an Image or Cover block with the same ratio.

The components that arrive approximated

Some shadcn/ui components depend on state: open or closed, active tab, current slide. WordPress can show one of those states in static markup, so a conversion picks the default one and keeps the content.

This is usually the right trade for a marketing page. A features section built with Tabs still shows its first panel, with real text that a client can edit. It no longer switches panels.

Plan for these before you convert, and decide which ones you want to rebuild with a block plugin afterwards.

Tabs → the panel that was open by default, rendered as a normal section. The tab strip may be kept as headings or dropped.
Dialog, Sheet, Popover, Dropdown, Tooltip → default state only. A dialog that starts closed contributes nothing visible; its content may be placed on the page or left out.
Carousel → the visible slides as a row or a stack, without the sliding behavior.
Skeleton and decorative mockup divs → approximated or dropped, since they carry no content.
Animations and transitions → the final state is kept, so an element that fades in is simply there.
Responsive utilities → desktop values are kept. WordPress stacks columns on small screens with its own rules, so check mobile after conversion.

The components that do not convert

Some shadcn/ui usage is not design at all. It is application logic. That part belongs to React, and there is no honest mapping to a block.

Forms are the clearest example. A shadcn/ui Form is React Hook Form plus Zod validation plus a submit handler. The fields are visual, the behavior is not. A conversion can give you a working contact form through Contact Form 7, with the same labels and order, but the validation rules and the submit handler do not travel.

Anything that talks to a backend has the same problem. Supabase queries, authentication, dashboards, charts fed by API calls, third-party widgets, canvas and Lottie are not converted. Screens behind a login are reported rather than converted. If your Lovable project is mostly an app, read Converter vs manual rebuild vs headless before you pick a path.

Form → rebuilt as a Contact Form 7 form; custom validation and handlers are not carried over.
Command palette, Combobox, Calendar, Date picker → interactive, not converted.
Toast and Sonner → runtime notifications, nothing to render.
Charts → not converted; use a WordPress chart plugin or an exported image.
Anything reading Supabase or an API → not converted.

Where Tailwind tokens go

The part people worry about most usually survives best. Tailwind config and the CSS variables that shadcn/ui uses for colors are design tokens, and WordPress has a place for design tokens: theme.json.

Colors become palette entries. The type scale becomes font sizes. Google Fonts used by the project are bundled into the theme and declared in theme.json, so the Site Editor offers them in the font picker. Spacing follows the layout values of the sections it came from.

The practical effect is that an editor who opens Appearance → Editor sees your brand colors by name, not hex codes pasted into blocks. Change one palette value and every block using it updates. That is closer to how shadcn/ui worked than most people expect.

Component-level utility classes that have no token equivalent are handled per block, as block style attributes or as CSS in the theme stylesheet.

Doing the mapping without hand-writing block markup

You can rebuild each page in the Site Editor by hand. It works, and it is the right choice for a small site you want to restructure anyway. For a multi-page Lovable project it is slow, because every card, grid and heading has to be placed again.

Our converter does the mapping described above and outputs a WordPress block theme: templates, header and footer template parts, one pattern per page, theme.json with your palette and fonts, and your images copied into the theme. It takes the Lovable ZIP or a GitHub repository, runs in the browser, and the conversion, the review and the theme download are free.

The review screen shows the converted site next to the original inside WordPress Playground, so you can check each shadcn/ui section before you install anything. An AI fix agent can read the source project, compare both pages and edit the theme when a component landed badly. Every account includes two free fix attempts.

The full list of what converts, what is approximated and what is left out lives on Supported features.

Export the project from Lovable with GitHub sync or a ZIP download. See How to export Lovable code.
Open iqdesk.com/app and upload the ZIP or connect the repository.
Review the converted pages side by side with the original in the browser.
Fix the sections that landed wrong with an AI instruction, up to 2,000 characters each.
Download the theme and install it in WordPress: Appearance → Themes → Add New → Upload Theme → Activate.
Rebuild the interactive parts with plugins: Contact Form 7 for forms, WooCommerce for products, a block plugin for tabs or sliders if you need them.

What to check after the theme is live

Block themes stack columns on mobile by default, so the first pass should be on a phone. Grids that were three across at desktop width become one column. Decide whether that is fine or whether the section needs regrouping in the Site Editor.

Then check the components that were approximated. Open every page where a Tabs, Carousel or Dialog used to be and confirm the remaining content reads correctly on its own. A tab label with no panel behind it is worse than no label at all.

Finally, handle the WordPress side of launch. If you built on a staging URL, Settings → Reading has a checkbox called "Discourage search engines from indexing this site". Uncheck it before launch. Set the front page under Settings → Reading → "Your homepage displays" and confirm the permalink structure under Settings → Permalinks.

For anything about Lovable itself that is not covered here, check Lovable's documentation.

FAQ

Can I use shadcn/ui components in WordPress?

Not as components. shadcn/ui is React source code, and a WordPress block theme renders HTML on the server with no React runtime on the front end. You can reproduce the look with core blocks and a theme.json palette, which is what a conversion does. Running the actual components would require a headless setup where WordPress serves only the content API.

Which shadcn/ui components convert to WordPress blocks one to one?

Card, Button, Accordion, Separator, Avatar, Table, Blockquote, lists and navigation menus all have close core block equivalents. Card becomes columns with an image, heading and paragraph. Accordion becomes the core Details block, which needs no JavaScript. These keep their content and stay editable in the Site Editor.

What happens to shadcn/ui tabs, dialogs and carousels?

They are approximated in their default state. A Tabs component contributes the panel that was open by default, a carousel contributes its slides as a static row or stack, and a dialog that starts closed contributes nothing visible. The text survives, the interaction does not. You can rebuild the behavior with a WordPress block plugin afterwards.

Do my Tailwind colors and fonts carry over to WordPress?

Yes. Tailwind colors become palette entries in theme.json, the type scale becomes WordPress font sizes, and Google Fonts used by the project are bundled into the theme. Editors then pick your brand colors by name in the Site Editor instead of pasting hex codes. Utility classes with no token equivalent are applied per block or in the theme stylesheet.

Does a shadcn/ui form still work after conversion?

The fields and labels are rebuilt as a Contact Form 7 form, so visitors can submit messages. The React Hook Form validation rules and the original submit handler are not carried over, because they are application logic rather than markup. Anything that talked to Supabase, an API or an authentication system has to be rebuilt in WordPress.

Convert a Lovable site to WordPress All guides