14 shadcn Alternatives in 2026: Price, Mobile and MCP

Picking among shadcn alternatives usually starts with how each library installs and how it looks. The questions that decide a project come later: what happens to the files you copied when upstream fixes a bug, whether the select you ship opens as something usable on a 390px phone, and whether Claude Code or Cursor can look up real props instead of guessing them. This guide answers those questions for 14 libraries, with prices, licenses and features checked in October 2026 and linked to the pages we read.

We build Wingo UI, one of the paid options below, so read this as a vendor's view with sources. It covers open source shadcn alternatives and paid ones, and it says plainly where another library is the better pick. More head to head comparisons live under Comparisons and alternatives.

What is the best alternative to shadcn UI?

There is no single best alternative to shadcn UI, because shadcn/ui is three things at once: a way to distribute code (a CLI that copies source files into your project), a set of primitives underneath (Base UI, Radix or React Aria), and a visual style. Decide which of the three you want to replace and the shortlist gets short:

• Keep the model, change the components. coss ui for free MIT components on Base UI, Magic UI or Aceternity UI for animated landing pages, Untitled UI React for a kit that matches the Untitled UI Figma file, Wingo UI for mobile-first app components with an MCP server and updates that merge into files you edited.
• Leave the model, install a package. Mantine for a free set with forms, dates and charts, MUI when you need the MUI X data grid and pickers, Chakra UI for style props, HeroUI for React Aria and Tailwind CSS v4 in an npm package, Ant Design for dense enterprise back offices.
• Keep the primitives, drop the look. Base UI, React Aria Components or Radix Primitives, styled by you.
• Step outside React. daisyUI, which is a set of Tailwind CSS class names that works with any framework.

If none of those reasons applies to you, the best option may be staying where you are, which the section near the end covers.

What changed in shadcn/ui in 2026?

The biggest change: since July 2026, new shadcn/ui projects start on Base UI instead of Radix. The July 2026 changelog entry (opens in a new tab) made Base UI the default for npx shadcn init and for the docs, kept Radix fully supported behind npx shadcn init -b radix, and noted that projects created on shadcn/create were already picking Base UI over Radix 2 to 1. The same month, React Aria became a third base (opens in a new tab) (--base aria).

Other changes that matter when you compare:

• The Drawer (opens in a new tab) in Base UI projects now uses Base UI's drawer instead of Vaul. The Radix version still uses Vaul.
• June 2026 added components for chat interfaces, July 2026 a Toast built on Base UI, and September 2026 moved cn into its own package (opens in a new tab), so components import it from cn instead of @/lib/utils. What the new Toast means next to Sonner is in our Sonner alternatives comparison.
• On the agent side there is an MCP server (opens in a new tab) that browses, searches and installs from every registry in components.json, and a skill (opens in a new tab) (npx skills add shadcn/ui) that reads your project configuration before the agent writes code.

Two consequences follow. A "Radix plus Tailwind" description of shadcn/ui is out of date, and a registry written for Radix needs care in a new Base UI project. And the copy-the-source model has become a platform: registries from other vendors install through the same shadcn add command, so trying an alternative no longer means learning a new tool.

How do the shadcn alternatives compare?

The tables below are the short answer, checked in October 2026. "Mobile" lists only what each library's docs show for phones beyond responsive layout, and "Agents" what a coding agent can use. Prices are list prices on the day we checked; several vendors showed a discount from a higher price.

Libraries that put the source in your project

Packages and primitives

Two libraries are missing from the tables on purpose. Radix Primitives is still maintained and still the base of many registries, ours included; it appears in the section on headless primitives. Tailwind Plus, from the Tailwind CSS team, sells its components, templates and the Catalyst UI kit as a one-time purchase with lifetime access (opens in a new tab), but its product page sent us to a sign-in form when we checked, so we left it out rather than print prices we could not see.

Which alternatives keep the shadcn model?

coss ui, Magic UI, Aceternity UI, Untitled UI React and Wingo UI all put the source in your repository, and all but Untitled UI install through the shadcn CLI. They differ in what they cover and in what happens after the copy.

coss ui is the closest thing to shadcn/ui with a different design. Its registry components are MIT licensed, built on Base UI from the start, cover the app basics from Accordion and Dialog to Toast and Tooltip, and come with a migration guide from shadcn/ui and Radix. Its repository (opens in a new tab) also keeps Origin UI, the Radix-based registry coss ui grew out of, as a legacy snapshot with limited support. If you liked shadcn/ui and want more components on the new default base for free, start here.

Magic UI and Aceternity UI are effect libraries for marketing pages: animated backgrounds, marquees, hero sections and full landing templates. They sit next to shadcn/ui more than they replace it, since neither covers the forms, menus and overlays an app needs. Magic UI's free components are MIT; Aceternity uses its own license, which says you cannot redistribute the source files, so read it before you publish them in a public repository.

Untitled UI React is the code side of the Untitled UI Figma kit, installed with its own CLI (npx untitledui@latest add) or from npm. The free base is MIT; the PRO tier is a one-time purchase per seat tier and adds hundreds of components, dashboards and page examples, drawers, modals and command menus included. It is a natural pick when your designers already work from the Untitled UI Figma file.

Wingo UI is ours. Release 1.7.0 has 326 items: 218 components, 72 blocks and page templates, 17 hooks and 19 helpers, of which 75 are free. Every component is built for apps people open on phones, as the mobile section below shows. Every visual aspect is a prop with a default, and the CLI merges new releases into files you have edited. The weak spots: it is younger and has a much smaller community than shadcn/ui, it is React only, it is built on Radix (so a Base UI project would carry two primitive libraries), and most items need a paid plan.

Which alternatives ship as an npm package?

Mantine, MUI, Chakra UI, HeroUI and Ant Design. You upgrade with npm update instead of merging files, and you customize through the library's theme and style APIs instead of editing the component source. That trade is right for many teams: someone else fixes the focus trap in the date picker, and you never see the file.

Mantine 9 is free and MIT across the board: components, hooks, a form library, dates and charts. It does not use Tailwind CSS; its own FAQ has a page on the limits of mixing in third-party styling. Its AI guide (opens in a new tab) documents llms.txt, skills and an MCP server whose get_item_props tool returns a component's props or a hook's signature.

MUI is where you go for heavy data screens. The core Material UI library is MIT and free; the MUI X Data Grid, date range pickers, charts and tree view add advanced features in paid plans, listed at $299 (Pro) and $599 (Premium) per developer per year in October 2026. The default look is Material Design, which is a feature or a problem depending on your product.

Chakra UI 3 rebuilt the library on Ark UI and kept its style props. Its responsive object syntax reaches component props too: the Drawer docs show placement={{ mdDown: "bottom", md: "end" }}, which opens a bottom drawer on phones and a side panel from md. Chakra UI Pro sells blocks on top, from $299 one-time.

HeroUI 3 is the closest npm package to the shadcn stack: React Aria Components underneath, Tailwind CSS v4 for styling, MIT. Its Modal placement defaults to auto, which sits at the bottom of the screen below the sm breakpoint and centered above it, and its button styles (opens in a new tab) make the default size 40px tall on phones and 36px from md up. A separate HeroUI Native library covers React Native, and a paid HeroUI Pro adds components such as a command palette and a data grid.

Ant Design 6 is built for enterprise back offices: dense tables, forms and admin layouts. Phones get a separate library, antd-mobile, so an app that serves both maintains two sets of components.

Should you use headless primitives instead?

Only if you are building your own design system and can own every style, state and animation. Headless libraries give you behavior and accessibility; everything you see is your code.

• Base UI reached v1.0.0 on December 11, 2025 (opens in a new tab) and is now the default base under shadcn/ui. Its Drawer handles swipe to dismiss, the job shadcn/ui used Vaul for.
• React Aria Components from Adobe has the most thorough interaction layer we know of. usePress handles mouse, touch, keyboard and screen readers through one API, and useHover ignores the emulated mouse events that touch devices fire (opens in a new tab), which is the cause of hover styles that stick after a tap.
• Radix Primitives is still maintained and still under most of the shadcn ecosystem, including Wingo UI.

Picking a headless library also picks the base for everything you add later, since a registry built for one base may not drop cleanly into another.

Which shadcn alternatives work best on mobile?

Most of them leave the phone to you. They give you a drawer and a media query hook, and you wire the swap from popover or dialog to sheet one component at a time. Sorted by how much of that work the library does, from least to most:

1. Responsive CSS only. Magic UI and Aceternity UI (effects for landing pages) and Ant Design (a separate mobile library).
2. A recipe you copy per component. shadcn/ui, MUI and Mantine document a pattern that reads a media query and renders a different component or a full-screen variant.
3. A placement that changes by breakpoint. Chakra UI's drawer placement, daisyUI's modal-bottom sm:modal-middle and HeroUI's auto placement move the panel to the bottom of the screen on phones. Whether you can drag it away depends on the component.
4. Built into each component. Konsta UI, for mobile-only apps with an iOS or Material look, and Wingo UI, where the Popover, Select, Dropdown Menu, Dialog and date pickers open as draggable bottom sheets below 768px through a responsive prop that defaults to true.

Level 2 looks like this. It is an abridged copy of the responsive example in the shadcn/ui Drawer docs, where the form is shared as its own component and the overlay shell is written twice:

const isDesktop = useMediaQuery("(min-width: 768px)");

if (isDesktop) {
  return (
    <Dialog open={open} onOpenChange={setOpen}>
      {/* trigger, header and <ProfileForm /> */}
    </Dialog>
  );
}

return (
  <Drawer open={open} onOpenChange={setOpen}>
    {/* the same trigger and header again, then <ProfileForm /> */}
  </Drawer>
);

That is fine for one dialog. It becomes a project when every popover, select, dropdown and date picker needs the same treatment, each with its shell written twice and each reading a hook that returns false on the server. Our mobile-first React components guide covers why that hook value is harmless for overlays and harmful for content, along with the other rules for phones.

The level 4 version of the same idea is one component. The free Drawer is a draggable bottom sheet on phones, and its desktop prop decides what it becomes from 768px: the same sheet ("sheet", the default), a side panel ("side") or a centered dialog ("dialog").

"use client";

import { SlidersHorizontal } from "lucide-react";
import { Button } from "@/components/ui/button";
import { Drawer, DrawerClose } from "@/components/ui/drawer";

export function ListingFilters({ results }: { results: number }) {
  return (
    <Drawer
      trigger={
        <Button variant="soft" leftIcon={<SlidersHorizontal />}>
          Filters
        </Button>
      }
      title="Filters"
      description="New York · 1,240 listings"
      desktop="dialog"
      closeLabel="Close filters"
      footer={
        <DrawerClose asChild>
          <Button size="lg" fullWidth>
            Show {results} results
          </Button>
        </DrawerClose>
      }
    >
      <p className="text-sm text-muted-foreground">Price, condition and categories</p>
    </Drawer>
  );
}

On a phone the sheet has a drag handle and no close button; in the desktop dialog a close button appears in the corner, and closeLabel is its accessible name.

Touch targets follow the same split. HeroUI v3 makes its buttons taller below md, as noted above. Wingo UI's Button grows its medium size from 40px to 44px on coarse pointers and gives the small size a 44px hit area without changing how it looks. For the phone question alone, our best React component library for mobile comparison checks nine libraries at 390px, Ionic React and antd-mobile included, on sheets, touch targets, safe areas and gestures.

Which shadcn alternatives work best with coding agents?

In October 2026 most of them have an MCP server, so the useful question is what the server can do. We see three kinds:

• Documentation servers answer questions about components, props and examples, and npm still installs the package. MUI, Mantine (search_docs, get_item_props, get_api), Chakra UI (list_components, get_component_props, get_theme), Ant Design (eight tools behind antd mcp, antd_changelog among them), React Aria and HeroUI work this way.
• Install servers find items and put their source into your project. The shadcn MCP server does it through the shadcn CLI for any registry in components.json, and Untitled UI's server can browse, search and install its components. Magic UI's gives the agent direct access to its components.
• Servers that also check for updates. Ours answers searches and returns props with defaults, the design rules and the theme tokens without an account, and sends the source to an API key (a free account for free items, Pro for the rest). Its check_updates tool compares the versions in your wingo-ui.json with the latest release, so the agent hears about fixes before it edits a file that has one waiting.

Setting each one up takes one line:

# documentation servers: the agent reads props and examples, npm installs the package
claude mcp add mantine -- npx -y @mantine/mcp-server
claude mcp add chakra-ui -- npx -y @chakra-ui/react-mcp

# an install server for every registry in components.json
npx shadcn@latest mcp init --client claude

# the Wingo UI MCP server plus a rules file for the agent
npx wingo-ui@latest agents install claude

The server matters more for libraries whose source you own. With a package, an agent that guesses a prop gets a type error. With copied source, the agent can edit the component itself, so it needs the real API and the rules behind it. Our guide to component library MCP servers covers the tools, the rules file and the setup for Claude Code, Cursor and Codex.

How do you update components you copied?

With a package, you run npm update and read the changelog. With copied source, the merge is yours, and libraries differ in how much they help.

The shadcn CLI can preview: npx shadcn@latest add dialog --dry-run lists what would change and --diff shows the difference for a file. Bringing an upstream fix into a file you have edited is then a manual merge, or a job for your agent with the shadcn skill loaded. Every registry you install through the shadcn CLI behaves the same way. Our guide to updating shadcn components without losing edits turns that manual merge into a git 3-way merge.

Wingo UI's CLI records the version of everything it installs in wingo-ui.json and keeps the installed copy in .wingo-ui/base/, which lets it run a three-way merge, the same idea as git merge:

npx wingo-ui@latest outdated              # installed vs latest, and which files you edited
npx wingo-ui@latest diff drawer --base    # what you changed since installing
npx wingo-ui@latest update drawer         # untouched files are replaced, your edits are kept

When upstream and you changed the same lines, the file gets conflict markers and you choose, or you settle every conflict with --theirs or --ours. The updates docs cover the details. One caveat: files you install through the shadcn CLI from our registry carry no version record, so wingo-ui update cannot merge into them later.

Which shadcn alternatives include a data table?

MUI, Ant Design and Wingo UI ship a full data table; shadcn/ui gives you a guide instead. Its Data Table page (opens in a new tab) explains that one data table component would lose the flexibility of headless UI, so it walks you through building your own on the Table component and TanStack Table v9. That is a good fit if your tables are all different. If you need the same admin table on twenty screens, the guide becomes code you maintain. Our TanStack Table v9 data table tutorial builds that code with filters, bulk actions and server pagination, and compares it with the ready-made tables.

The alternatives split three ways. MUI's X Data Grid has a free MIT version and adds its advanced features in the paid plans. Ant Design's Table has sorting, filters and pagination built in, and the other packages give you a styled table to build on. Wingo UI's Data Table is a Pro component on TanStack Table v9 with search, filters, sorting, bulk actions, pinning, resizing and virtualization, and below 768px each row becomes a card instead of a table that scrolls sideways:

"use client";

import { DataTable, createColumns } from "@/components/ui/data-table";

type Order = { id: string; customer: string; city: string; status: string; total: number };

const col = createColumns<Order>();
const columns = col([
  col.accessor("customer", { header: "Customer", filter: "text", mobile: "title" }),
  col.accessor("city", { header: "City", filter: "multi-select", mobile: "subtitle" }),
  col.accessor("status", {
    header: "Status",
    type: "badge",
    badge: { Paid: { tone: "success" }, Refunded: { tone: "warning" }, Failed: { tone: "danger" } },
    filter: "multi-select",
  }),
  col.accessor("total", { header: "Total", type: "currency", footer: "sum" }),
]);

export function Orders({ orders }: { orders: Order[] }) {
  return (
    <DataTable
      data={orders}
      columns={columns}
      caption="Orders"
      locale="en-US"
      selectionMode="multiple"
      searchPlaceholder="Search orders"
      mobileLayout="cards"
    />
  );
}

The mobile key on a column decides where its value goes on the phone card: "title", "subtitle", "meta", "field" or "hidden". Rows need a unique id (or pass getRowId), because selection uses it. Switch mobileLayout to "scroll" when a table has to stay a table.

Which shadcn UI alternative for React fits your project?

Match the library to the job. These are our picks, including the many cases where the answer is not ours:

• Enterprise admin with heavy grids and date ranges: MUI with MUI X, the deepest set of data components in this list.
• Internal tools with complex forms, without Tailwind: Mantine. Free, MIT, with forms and dates built in.
• A design system of your own: Base UI or React Aria Components. React Aria if touch and screen reader behavior has to be exact.
• A free shadcn alternative on the new default base: coss ui.
• An npm package with the shadcn look and stack: HeroUI 3.
• Animated marketing pages: Magic UI or Aceternity UI, next to whatever you use for the app.
• Server-rendered pages with little JavaScript, or a stack beyond React: daisyUI.
• A mobile-only web app, or one wrapped in Capacitor, with a native iOS or Material look: Konsta UI.
• A product that people use on phones and desktops, built with coding agents, where you own the source and still want updates: Wingo UI.

When should you stay on shadcn/ui?

Stay when your app is used mostly on desktops, your team is happy to write its own responsive wrappers, and the biggest ecosystem matters more to you than any one feature. shadcn/ui is free and MIT licensed, its GitHub repository (opens in a new tab) had about 125,000 stars on October 8, 2026, it supports three bases, and its CLI installs from a whole directory of community registries. Switching has a cost: every call site that uses a component's API changes, and a new library brings its own conventions for tokens, sizes and states.

You also do not have to choose. Because registries share one CLI, the realistic path for most teams is shadcn/ui as the base plus one or two registries for what it lacks.

How do you switch without a rewrite?

Replace one component at a time, starting with the ones that hurt most, and keep both libraries in the project while you do.

Three practical points for a move from shadcn/ui to Wingo UI, most of which apply to any registry:

1. File names collide. Both libraries write components/ui/button.tsx, dialog.tsx and drawer.tsx. Our CLI keeps an existing file that differs and tells you to rerun with --overwrite, so commit first and swap deliberately.
2. Call sites change. shadcn/ui's Button uses variant="destructive" and variant="secondary"; ours separates the role from the color, so those become tone="danger" and variant="soft".
3. Pick the right CLI for a Base UI project. Free items install from their URL with npx shadcn@latest add https://wingo-ui.com/r/button.json, and Pro items through the @wingo-ui registry in components.json. But shadcn projects created with a Base UI style rewrite asChild, which our components rely on, so in those projects use npx wingo-ui@latest add instead, as the installation docs explain.

To keep the new components close to your current look while you migrate, set app-wide defaults once instead of passing props everywhere. Our Button and Input default to radius="md", which gives the medium size 10px corners; if your current controls use 8px, "sm" matches them:

import { UIProvider } from "@/lib/ui-config";

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body>
        <UIProvider defaults={{ button: { radius: "sm" }, input: { radius: "sm" } }}>
          {children}
        </UIProvider>
      </body>
    </html>
  );
}

UIProvider is a client component, so the root layout can stay a server component. Explicit props still win over these defaults, and the defaults win over the component's own. The Button below runs with the soft variant and a full radius set through props, so you can compare it with your current buttons in both themes.

Where should you start?

Pick the one component that hurts most on a phone and try an alternative for that component alone. If it is an overlay, install the free Drawer with npx wingo-ui@latest add drawer (no account needed; it brings the Button and the media query hook along), put it behind one trigger people use on phones, and open it on your own device. The Data Table and the rest of the catalog are part of Wingo UI Pro, and the MCP server answers questions about every item without an account, so your agent can read the props before you decide.

FAQ

What is the best free alternative to shadcn/ui?

If you want to keep owning the source, coss ui is the closest match: MIT licensed, built on Base UI and installed through the shadcn CLI. If you would rather install a package, Mantine is MIT licensed, free and covers forms, dates and charts as well as the basic components.

Is shadcn/ui still built on Radix?

Not by default. Since July 2026, npx shadcn init starts new projects on Base UI, Radix stays fully supported with the -b radix flag, and React Aria is available as a third base with --base aria.

Which shadcn alternative works best on mobile?

Konsta UI if you want an iOS or Material look for a mobile-only web app, and Wingo UI if the same app runs on desktops and phones, because its popover, select, menus and dialog open as draggable bottom sheets below 768px by default. HeroUI, Chakra UI and daisyUI can move a modal or drawer to the bottom of the screen on phones; shadcn/ui, MUI and Mantine document a recipe you wire per component.

Can I use a shadcn alternative alongside shadcn/ui?

Yes. Registries such as coss ui, Magic UI, Aceternity UI and Wingo UI install through the same shadcn add command, so you can replace one component at a time. Watch for files with the same name, such as components/ui/button.tsx, and commit before each swap.

Do shadcn alternatives work with Claude Code and Cursor?

Most do. As of October 2026 shadcn/ui, MUI, Mantine, Chakra UI, HeroUI, Ant Design, React Aria, Magic UI, Untitled UI and Wingo UI publish MCP servers, and nearly all publish llms.txt. The servers differ: some answer documentation questions, some install source files, and Wingo UI's also checks your installed versions for updates.