Radix vs Base UI: which headless React library should you use in 2026?

Radix vs Base UI is the most important comparison in the headless React ecosystem right now. Both libraries provide unstyled, accessible primitives for building production UIs. Radix has 19,000 GitHub stars, 30+ components, and powers millions of apps through shadcn/ui. Base UI reached v1.0 stable in December 2025 with 35 components, full-time MUI engineering, and a render-prop API designed from the lessons Radix taught the ecosystem. As of July 2026, shadcn/ui defaults to Base UI for new projects — but Radix is not deprecated.

Whether you search for it as radix vs base ui or base ui vs radix ui, this post breaks down every technical difference between the two libraries so you can make an informed choice. At the package level it is base-ui vs radix-ui — @base-ui/react versus radix-ui — and the differences run deeper than the npm names suggest.

Jump to: What they are · Comparison table · API design · Bundle size · Components · Why the shadcn default changed · Which to choose · FAQ

What are Radix UI and Base UI?

Radix UI and Base UI are both headless (unstyled) React component libraries. They handle accessibility, keyboard navigation, focus management, and ARIA semantics. You bring your own CSS.

Radix UI launched in 2022 and became the default primitive layer for shadcn/ui. It is maintained by WorkOS. Base UI is built by MUI — the team behind Material UI, which has 95,000+ GitHub stars and 5.8 million weekly npm downloads. Base UI shipped its stable v1.0.0 release on December 11, 2025.

Here is the key fact most developers miss: several of the engineers who originally built Radix now work on Base UI. As shadcn stated in the July 2026 changelog, "the same folks who built Radix are building something new: Base UI. They've done it once. Now they get to do it again, with everything they learned the first time."

Both libraries use the MIT licence and both support React 17, 18, and 19. If you are weighing more than these two primitive layers, our roundup of the best React UI libraries in 2026 ranks the full field by use case.

Radix vs Base UI compared: the full technical breakdown

This table compares Radix UI and Base UI across every dimension that matters for production React applications.

How does the API design differ between Radix and Base UI?

The API design is the most visible difference between Radix vs Base UI. Both use compound components, but Base UI adds a render prop for element-level control. Radix uses asChild with the Slot pattern instead. Here is the same Dialog built with each library.

Key differences: Radix uses asChild to merge props onto your own element; Base UI accepts className directly on its parts, so you skip asChild in most cases. Radix names its surface Dialog.Content and its backdrop Dialog.Overlay; Base UI names them Dialog.Popup and Dialog.Backdrop.

The render prop in Base UI replaces asChild with a more explicit pattern that avoids the prop-merging ambiguity asChild sometimes causes with event handlers and refs:

The same abstraction sits under shadcn/ui either way — our shadcn button examples guide covers the Base UI primitive backend alongside the Radix one.

How does accessibility compare between Radix and Base UI?

Both Radix and Base UI follow WAI-ARIA patterns for every component. Both handle keyboard navigation, focus trapping in modals, screen reader announcements, and ARIA attributes automatically. The practical difference is in edge cases.

Base UI v1.0 shipped with built-in RTL support — every component respects dir="rtl" without additional configuration. Radix requires manual RTL handling in several components. Base UI also ships a CSPProvider for applications with Content Security Policy restrictions, which Radix does not provide out of the box. For form integration, both expose a consistent name and value API, but Base UI's form handling is more consistent across its full component set.

How does bundle size compare between Radix and Base UI?

Bundle size matters for landing pages where every kilobyte affects Core Web Vitals. Both libraries are tree-shakeable, so you only pay for the components you import. Here is a comparison for four common components (minified + gzipped, approximate).

Base UI is consistently smaller because it was designed without the accumulated backwards-compatibility weight that Radix carries. The difference is small per component, but it compounds: a typical shadcn/ui project uses 15–25 primitive components, so the cumulative saving is meaningful for landing page performance. If you are building a shadcn landing page template, every kilobyte you save from the primitive layer directly improves your Lighthouse score.

How do Radix and Base UI handle animations and transitions?

Both libraries expose data-state attributes (data-state="open", data-state="closed") that you target with CSS transitions. Base UI adds a keepMounted prop on components like Dialog, Popover, and Tooltip so your CSS exit animation completes before the element unmounts. Radix supports this through forceMount, but the API is less consistent across components.

The difference worth seeing is exit animation. By default, a closing component unmounts immediately — it snaps out of the DOM before any transition can run. keepMounted keeps the element mounted so the close animation plays. Toggle the demo below: the left panel vanishes instantly, the right one fades and scales out.

Base UI also exposes [data-open] and [data-closed] custom attributes alongside [data-state]. shadcn/ui uses these through its shadcn/tailwind.css custom variants:

Which components does each library offer?

Base UI ships 35 components as of v1.6.0. Radix ships 30+ primitives in the unified radix-ui package (v1.6.1). The coverage overlaps heavily, but each library leads in a few places.

Where Base UI leads: Autocomplete, Combobox, Number Field, and Drawer — the components Radix users have requested for years. The Combobox gap is the most cited reason developers switch from Radix to Base UI. Where Radix leads: Context Menu, Hover Card, and Toast, which do not exist in Base UI yet. Whichever primitive is underneath, the styled layer is the same — browse the full set in our shadcn components directory.

How does each library work with Tailwind CSS?

Both libraries are style-agnostic and expose data attributes for state-based styling. With Tailwind CSS, you target these with data-* variants. The integration is nearly identical — the main difference is the attribute name.

Radix uses data-[state=open]; Base UI uses data-[open] — shorter and cleaner. Radix names accordion content Accordion.Content; Base UI names it Accordion.Panel. If you use ShadcnDeck templates, the Tailwind styling layer is identical regardless of the primitive underneath — the shadcn abstraction makes the primitive layer transparent.

Why did shadcn/ui make Base UI the default?

In July 2026, shadcn/ui officially made Base UI the default for new projects — the most significant architectural decision in shadcn/ui's history. Here is the timeline.

shadcn gave three reasons in the July 2026 announcement:

• The community already chose it. Projects created on shadcn/create picked Base UI over Radix 2-to-1 before the default changed. The data drove the decision.
• Same engineers, second iteration. The core engineers who built Radix primitives now work on Base UI at MUI, applying everything they learned the first time.
• Active maintenance. Base UI ships monthly releases with a full-time team. Radix has slower update velocity, particularly for complex components like Combobox and multi-select.

You do not need to migrate. shadcn was explicit: Radix is not deprecated, and every update ships for both libraries. To keep using Radix in new projects, add the -b radix flag:

The shadcn abstraction layer means your component API stays the same either way — the import @/components/ui/dialog works identically for Radix and Base UI. You own the code; the primitive layer is an implementation detail the abstraction hides.

Radix vs Base UI: which should you choose for a new project?

Choose Base UI if:

• You are starting a new project in July 2026 or later.
• You need Combobox, Autocomplete, or Number Field components.
• You want the faster release cycle and active maintenance from MUI's team.
• You are using shadcn/ui (it is now the default).

Choose Radix if:

• You have an existing production app built on Radix — do not migrate without a reason.
• You need Context Menu, Hover Card, or Toast primitives that Base UI does not offer yet.
• You prefer the established ecosystem with 131 million weekly npm downloads via its Slot package.

Either way, the shadcn abstraction lets you switch primitive layers later without rewriting component code. For landing pages and SaaS sites, free shadcn/ui landing page templates from ShadcnDeck ship with the Base UI default and give you a production-ready starting point in minutes. If you are choosing across the whole ecosystem, our shadcn vs Material UI and Mantine vs shadcn comparisons cover the styled-library layer above these primitives.

How to migrate from Radix to Base UI in a shadcn/ui project

Because shadcn/ui abstracts the primitive layer, you do not rewrite application code — you replace the underlying component files. Point components.json at Base UI, then re-add your components with --overwrite:

Test animation timing (Base UI's keepMounted differs slightly from Radix's forceMount), custom event handlers on asChild / render components, and any direct @radix-ui/* imports in your own code. For complex apps, migrate component by component — both libraries coexist without conflict.

Frequently asked questions

The bottom line

Radix and Base UI are both MIT-licensed, headless, and production-ready. Choose Base UI for new projects, the faster release cycle, and components like Combobox and Autocomplete. Choose Radix when you have an existing Radix codebase or need Context Menu, Hover Card, or Toast. Because shadcn/ui hides the primitive layer, you can start with either and switch later — so the safer bet is to start shipping.

If you are starting a new project today, skip the build entirely with a production-ready shadcn/ui template.