---
title: July 2026 - Base UI as the Default
description: New projects now use Base UI by default. Radix is still fully supported.
date: 2026-07-02
---

Starting today, **Base UI is the default component library in shadcn/ui**.

<div className="mt-6 flex w-full items-center justify-center rounded-2xl bg-muted/50 py-32 text-foreground ring ring-border dark:bg-muted">
  <svg width="17" height="24" viewBox="0 0 17 24" className="size-16">
    <path
      fill="currentColor"
      d="M9.5001 7.01537C9.2245 6.99837 9 7.22385 9 7.49999V23C13.4183 23 17 19.4183 17 15C17 10.7497 13.6854 7.27351 9.5001 7.01537Z"
    />
    <path
      fill="currentColor"
      d="M8 9.8V12V23C3.58172 23 0 19.0601 0 14.2V12V1C4.41828 1 8 4.93989 8 9.8Z"
    />
  </svg>
</div>

First, a bit of history. When shadcn/ui launched in January 2023, it was built on Radix. At the time, nothing else came close. Unstyled headless components, great APIs, great accessibility, battle-tested in millions of apps.

Fast forward a few years and the same folks who built Radix are building something new: [Base UI](https://www.base-ui.com). They've done it once. Now they get to do it again, with everything they learned the first time.

Last year, Base UI tagged a beta and a lot of you asked if we are going to replace Radix with it. I said "the worst thing you can do for your production app is switch component libraries". I meant it, and it still holds. So instead of switching, we did the shadcn thing: we rebuilt every component for Base UI, kept the same abstraction, and let you choose. December brought `npx shadcn create` with both libraries. January brought full Base UI docs.

Then we watched what you did with it.

---

## Why Now

- **Base UI is stable.** It's at 1.6.0 with 6M+ weekly downloads.
- **It keeps getting better.** The team ships new and useful components regularly.
- **We use it.** Every new project we've started runs on Base UI.
- **You use it.** Projects created on shadcn/create now pick Base UI over Radix 2 to 1.

The community already made the call. We're making it official.

---

## What's Changed

- **New projects default to Base UI.** Run `npx shadcn init` and Base UI is the default pick.
- **shadcn/create shows Base UI first.**
- **The docs default to Base UI.** Component pages open on the Base UI tab. Radix docs are one click away.

## What This Means for You

**Radix is not being deprecated.** We still support it, and every update and new component will ship for both libraries (unless a component only exists in Base UI).

**You do not need to migrate.** Radix is a mature, tested library. We still run it in production today and we're not migrating. If your app works, keep shipping.

**Prefer Radix for new projects?** It's one flag away:

```bash
npx shadcn init -b radix
```

If you have scripts or CI running `shadcn init` non-interactively and expecting Radix, add `-b radix` to keep them on the same path.

**Building a registry?** Ship a `registry:base` config if you want to pin a specific library. Items without one now init as Base UI.

**Starting something new?** We recommend Base UI.

## When You're Ready to Migrate

You don't need to migrate. But if you want to, we built a skill for it:

```bash
npx skills add shadcn/ui
```

Then ask your coding agent:

```txt
migrate accordion to base-ui
```

It's progressive by default: migrate one component and its usage at a time while your project stays green and shippable. Both libraries coexist while you work. Stop halfway, ship, come back next week and it picks up where you left off. Or ask for the whole project in one go.

### Why a skill and not a codemod?

Because you own the code. You've added variants, changed classes, threaded new props. A codemod handles the components you never touched and breaks on the ones you did.

So we shipped knowledge instead: every rename, every prop change, every behavior difference, hand-checked against both libraries. Your agent reads it, figures out what _you_ changed, and carries those changes over.

Mechanical things get fixed everywhere (`asChild` is now `render`). Behavior changes get flagged, never silently patched. You decide.

### What a migration produces

Every run leaves three things:

- **Working code.** Typechecked and built before it reports success.
- **A report per component** in `.migration/` at your project root: what changed, what was left alone, and a short checklist of things to verify by hand.
- **Clean git history.** One commit per component, on a branch. Rollback is deleting the branch.

Here's what a report looks like:

```md title=".migration/accordion.md"
# accordion

<!-- date, strategy used, and the one-line verdict -->

## Changed

<!-- every file touched, with what changed and why -->

## Left alone

<!-- files that look related but were intentionally not touched -->

## Behavior changes

<!-- differences that compile fine but act differently. flagged, not patched -->

## Verify by hand

<!-- a short checklist: open, click, tab through. takes a minute -->
```

No hidden state. Progress lives in your files and git history, so any agent, any session, any day picks up where the last one stopped.

It works with Claude Code, Cursor, or any agent that supports skills. We tested it on real projects: 60+ components, 36 of them on Radix. A full migration ran in about 25 minutes at roughly 10k tokens per component. Clean builds, customizations intact.
