Base UI vs. React Aria Components: Which Headless React Library Should You Use in 2026?

If you're building a design system from scratch in 2026, you're almost certainly choosing between Base UI and React Aria Components. Radix is still supported and still maintained, but these two are where the momentum went.

They're solving the same problem — accessible, unstyled behavior you style yourself — and they're both very good at it. But they were built by different people with different priorities, and the component lists diverge more than most comparisons admit.

We should say where we stand: Untitled UI React is built on React Aria, so we've spent a lot of time in one of these libraries and rather less in the other. We've checked every claim against the published packages and docs rather than our impressions, and there are several dimensions where Base UI is clearly better.

Base UI vs. React Aria: which should you use?

Choose React Aria if accessibility depth, internationalization and screen-reader-tested behavior matter most. Adobe maintains it, it offers both hooks and components, and it ships dates, colors, tables and trees. Choose Base UI for a smaller, faster-to-write API, five dependencies, React 17 support and shadcn/ui alignment. Both are unstyled. React Aria trades verbosity for rigor.

Two questions decide it for most teams, and they're easier to answer than the marketing on both sites suggests. Do you need dates, colors, tables or trees? Do you ship in more than one language? If either answer is yes, React Aria, today. If both are no, Base UI is the more elegant library for that job.

Key takeaways

• Component coverage is the real dividing line. React Aria documents over 50 components including six date components and seven color components. Base UI ships 37 and none of those categories.
• Base UI has the better primitive API. The render prop, useRender, mergeProps and eventDetails with 35 typed change reasons are the best-engineered headless API in React.
• Internationalization isn't close. React Aria ships 34 locale bundles covering 32 languages and 13 calendar systems. Base UI ships no string catalog at all.
• Base UI has the bigger present; React Aria has the longer record. Base UI is shadcn/ui's default since July 2026; React Aria has been stable since 2023 and Adobe's own products depend on it.
• Neither is a risky choice. Both shipped releases on 4 September 2026.

Which "Base UI" are we talking about?

Worth clearing up before anything else, because at least four products share this name and no other comparison disambiguates all of them.

Be careful at install time. npm i baseui pulls down Base Web from Uber, a different project. Base UI ships as @base-ui/react.

The library's own history adds a second trap. Before 11 December 2025, when v1.0.0 renamed the package, it shipped as @base-ui-components/react. A coding agent that writes that import path is relying on stale training data.

Where these two sit among the headless UI libraries

Base UI and React Aria aren't the only headless UI libraries at this layer, and the comparison makes more sense with the others on the table.

• Radix UI: the library that defined the category, and still the most widely deployed of the headless components in React. Radix primitives introduced the pattern everyone else uses: unstyled components split into parts, state exposed as data attributes, composition instead of configuration. Still maintained, still enormous, still a perfectly good choice.
• Base UI: built by several of the people who built Radix UI primitives, plus the Floating UI and Material UI teams, with the benefit of hindsight on the API design.
• React Aria: Adobe's, and the widest of the four. It's the only one shipping dates, colors, tables and trees as accessible primitives.
• Ark UI: the multi-framework option, built on state machines and available for React, Vue, Solid and Svelte. If you're not React-only, Ark UI is the only one of the four that solves that problem. Chakra UI v3 is built on Ark UI, which is the clearest evidence it works as a foundation.

All four are the same kind of headless component library, not traditional component libraries: behavior, accessibility and state management, no visual design, the styling solution left to you. That shared shape is why picking between these headless libraries is harder than picking a styled one. The differences are coverage, API design, and how much of the accessibility problem each has solved.

A note on Ark UI, if you're not React-only

Worth a short detour, because a fair number of teams arrive at this comparison and discover neither answer fits.

Ark UI is the only headless component library in this group that ships the same components for React, Vue, Solid and Svelte, built on Zag's state machines. If your company has a React app, a Vue admin panel and a Svelte marketing site, Ark UI is how you get one set of behaviors across all three.

Its coverage sits between Base UI and React Aria: broader than Base UI on some categories, narrower than React Aria on dates and data. Chakra UI v3 is built on it, which is the strongest available evidence that it holds up under a real design system. Chakra UI is a styled library, so that's a headless foundation carrying a full design system in production.

The trade is that multi-framework support costs something. Ark UI's API is a little more abstract than Base UI's, because it has to be the same shape in four frameworks, and the React-specific polish is correspondingly thinner.

What happened to Radix primitives, and does it matter?

The short answer is no, and it's worth saying because it's the anxious subtext of every search here.

Radix UI is not deprecated, and it is not going anywhere. shadcn/ui's changelog says so explicitly, every new component still ships for Radix, and you can still initialize a project with -b radix. What changed is the default and the momentum: new projects get Base UI, and several of the people who wrote Radix primitives are now writing Base UI.

If you have Radix primitives in production and they work, there is no migration to run. If you're choosing today, Base UI and React Aria are where the active work is.

And what about MUI Base?

MUI Base is the other name that causes confusion, and it's the clearest of the four to resolve. MUI Base — the @mui/base package — is deprecated. Its own npm page says it "has been replaced by @base-ui/react".

So if you're reading a comparison that treats MUI Base as a live option, it predates December 2025. Its team and ideas went into Base UI, which is why the two get conflated. Practically: don't install it on anything new, and if you have it in a codebase, Base UI is the migration target its maintainers point you at.

The wider landscape is worth one sentence too. Traditional component libraries like Material UI, Chakra UI and Ant Design ship design and behavior together as a package you configure, which is the opposite trade from everything in this article.

Chakra UI v3 is an interesting hybrid, since it's built on Ark UI underneath, but it's still a styled library. None of those traditional component libraries is competing with Base UI or React Aria. They're competing with what you'd build on top of them.

What is Base UI?

base-ui.com — Open source (MIT) · ★10.9k · npm: ~9.71M/wk

Base UI is an unstyled React component library from the creators of Radix UI, Floating UI and Material UI. Its about page names Colm Tuite, Marija Najdova, Flavien Delangle, James Nelson, Jenna Smith, Michał Dudak and Aarón García.

It reached v1.0 in December 2025 and is on v1.8.0, published 4 September 2026. The pitch is the second attempt: the people who built Radix started over, and it shows most in the API design.

Base UI became shadcn/ui's default primitive layer in July 2026. Every new shadcn project installs it unless you opt out, a distribution advantage nothing else here can match and a substantial share of those 9.71 million weekly downloads.

Base UI key features:

• 37 documented components and 4 utils, focused on application chrome: menus, dialogs, popovers, navigation and form controls.
• Zero CSS. The published package contains 3,269 files and not one is a stylesheet.
• Five runtime dependencies: @babel/runtime, @base-ui/utils, @floating-ui/utils, @floating-ui/react-dom and use-sync-external-store.
• React 17, 18 and 19 supported.
• The render prop, typed as React.ReactElement | ComponentRenderFn, for replacing any part's rendered element.
• eventDetails on change handlers, carrying the reason, the native event, cancel(), allowPropagation() and the triggering element.
• shadcn/ui's default base, which means an enormous amount of Base UI code in the wild.

Base UI pros:

• The best primitive API in the category. The composition model is cleaner than anything else available, and eventDetails solves problems other libraries make you work around.
• Smallest dependency graph: five packages, all readable in one breath.
• Excellent documentation, including per-page markdown and an llms.txt that tells models to prefer the docs over their training data.
• Distribution through shadcn/ui, which is the widest reach any headless library has right now.
• Genuinely new, with no legacy API decisions to carry forward, and MIT licensed throughout.

Base UI cons:

• No dates, no colors, no table, no tree. These are among the hardest components to build and Base UI doesn't ship them.
• No localized strings. There's no bundled i18n layer, so accessible announcements in other languages are your problem.
• Younger, with less production mileage than a library Adobe has shipped for years.
• Accessibility is partly delegated: the docs are explicit that focus visibility and color contrast are the developer's responsibility.
• No formal support channel: GitHub and Discord only.

What are React Aria Components?

react-aria.adobe.com — Open source (Apache-2.0) · ★15.9k · npm: ~3.11M/wk

React Aria Components are Adobe's unstyled component library, built on the React Aria hooks that power React Spectrum, Adobe's own design system. The current release is 1.21.1, published 4 September 2026.

Its pitch is different from Base UI's. Adobe ships this because Adobe needs it. Photoshop on the web, Express and the rest of Creative Cloud run on this behavior layer, in dozens of languages, on every input device Adobe supports.

That origin explains most of what makes it distinctive: the component list is unusually long, the internationalization is unusually deep, and the interaction handling covers devices most libraries don't think about.

React Aria key features:

• Over 50 documented components, including 6 date components, 7 color components, Table, Tree, GridList and NavigationTree — the ones nobody wants to build twice.
• Zero CSS. Unstyled throughout, with a react-aria-ComponentName class on every component so plain CSS works with no setup.
• A documented hooks layer — useSelect, useComboBox, useTable, usePress, useFocusRing — for rebuilding the markup while keeping the behavior.
• 34 locale bundles covering 32 languages, plus 13 calendar systems through @internationalized/date.
• Accessible drag and drop with full keyboard parity, via DropZone and FileTrigger.
• Seven runtime dependencies, all first-party.
• React 16.8+, 17, 18 and 19 supported.
• A first-party Tailwind plugin, tailwindcss-react-aria-components, at around 392,000 weekly downloads.
• An official MCP server and a published agent skill, for teams generating code with AI.

React Aria pros:

• The widest component coverage in the category. Dates, colors, table and tree are the hardest things to build accessibly, and they're in the box.
• Published accessibility evidence. Adobe ships a screen reader support matrix and @react-aria/test-utils with testers for 11 ARIA patterns, so you can verify your own work.
• Internationalization nobody else matches, with RTL handled at the interaction level rather than mirrored in CSS.
• Two layers. When a component's DOM doesn't fit, you drop to the hooks rather than fork.
• Stable since December 2023 and funded by Adobe because Creative Cloud depends on it, which is the strongest longevity signal here.

React Aria cons:

• A larger surface to learn. Two layers and 50-plus components is more to hold in your head than 37 and a render prop.
• You carry capability you may not use. If you ship English-only with no dates, the locale bundles and @internationalized/date are weight for nothing.
• Apache-2.0, not MIT. Fine for almost everyone, but it's a patent-clause license and some legal teams treat that as a question.
• Smaller slice of the shadcn/ui world. It's available with --base aria, but Base UI is the default, so there's more Base UI code in the wild for humans and AI agents to copy.
• No formal support channel outside GitHub and Discord, despite the Adobe backing.

What you're signing up for either way

Choosing between these two is choosing which headless component library sits underneath a design system you still have to build.

Both are headless components in the strict sense: accessible primitives and nothing else. That means every color, radius, shadow, spacing value, focus ring, hover state, disabled state, empty state and dark mode variant is yours to design and maintain, for every component, forever.

For teams building custom design systems that's the point. That is precisely what these two were built for, and neither library is competing for the design work. It's why they exist.

For teams who want to ship a product, it's worth knowing before you start that the headless component library choice is maybe ten percent of the work. The Untitled UI React documentation is a reasonable way to see what the other ninety looks like once it's done. That part is design, and no comparison of accessible primitives will help you with it.

If that's where you are, the useful question isn't Base UI or React Aria. It's whether you should be choosing between headless libraries at all, or picking something built on one. We've written both of those comparisons: Untitled UI React vs. Base UI and Untitled UI React vs. React Aria Components.

Who each library is really for

• Base UI components suit teams building conventional application user interfaces from headless components — menus, dialogs, popovers, form controls — who value a clean API and a small dependency graph, and who are already in the shadcn/ui and Radix UI world.
• React Aria suits teams shipping complex components, multiple languages, or unusual markup, and anyone who'd rather inherit Adobe's decade of accessibility work than replicate it.
• Neither suits a team without a designer. Untitled UI React or shadcn/ui is the better starting point in that case. That's not a criticism of either library; it's what headless components are. Accessible primitives with no design attached are a foundation, not a product.

Comparison table: Base UI vs. React Aria Components at a glance

The headline numbers side by side, every one checked against the package registries and both documentation sites in September 2026. The sections that follow explain what each row means in practice.

Component-by-component comparison

This is the part most comparisons skip, and it's where the two libraries genuinely differ. We checked every row against both documentation sites rather than inferring from component names.

A note on naming, because several components exist in both libraries under different names. React Aria's Disclosure and DisclosureGroup are Base UI's Collapsible and Accordion. React Aria's Modal covers Base UI's Dialog. React Aria's ToggleButton is Base UI's Toggle. Those are matches, not gaps.

The shape of the difference is clear once you see it laid out. Base UI is stronger on application chrome: Menubar, Navigation Menu, Scroll Area, Avatar and OTP Field have no React Aria equivalent, and its Drawer is a dedicated component rather than a Modal pattern you assemble.

React Aria is stronger on data and input complexity: dates, colors, tables, trees, lists, tags and drag and drop have no Base UI equivalent at all. Those are the categories we ship as finished components on top of it: date pickers, calendars, color pickers, tables, tree views and file uploaders.

Verdict: React Aria Components on raw coverage, Base UI on app-shell primitives. If your product needs a date picker or a data table, that's decided for you today. Those are two of the hardest categories to build well, and only one library ships them.

What building the same thing in both actually looks like

Here's the same work in each of these headless UI libraries, using the two headless components everyone builds first.

A button

In Base UI, a button component is one part: <Button />, with a render prop for an anchor. React Aria's button is also one component, arriving with the react-aria-Button class name attached, so plain CSS works with no setup.

Underneath, React Aria normalizes press behavior across mouse, touch, keyboard and assistive tech, which is why it leaves no sticky hover state on mobile. Base UI's button component covers the same ground through Floating UI's interaction layer. Both are correct; React Aria has more public testing and broader documented screen reader support.

Either way, the styling solution decides more than the library does. A button in Tailwind CSS, a button in CSS Modules and a button in styled components are three files with identical behavior.

A dialog

A dialog is the better test, because it is where accessibility work lives: focus trapping, focus restoration, scroll locking, aria roles, escape handling, and the interaction with whatever opened it. Here's the same thing as finished React modal components.

Base UI's dialog is parts, in the style Radix primitives established: Dialog.Root, Dialog.Trigger, Dialog.Portal, Dialog.Backdrop, Dialog.Popup, Dialog.Title, Dialog.Description and Dialog.Close. Every part takes a className and exposes its state as data attributes, so a dialog's open and closing states are CSS selectors, not component state.

React Aria's dialog is DialogTrigger, Modal (or ModalOverlay) and Dialog, with Heading inside. Context does the wiring, so the heading becomes the accessible name without you passing an id.

Both ship accessible components: correct aria roles, proper focus management, screen reader support tested against real assistive tech. Base UI's dialog gives you more named parts to style; React Aria's gives you fewer decisions. They diverge on the alert dialog, which Base UI ships dedicated and React Aria leaves you to build from Dialog with an alert role.

To evaluate either, build a dialog with a form in it, submit it, close it, and tab back through the page. If focus management is wrong you'll find it in ninety seconds, the most common accessibility bug in custom design systems.

Which has better accessibility, Base UI or React Aria?

Both ship accessible components that follow WAI-ARIA authoring practices, and both treat accessibility as the product rather than a feature. Neither is a weak choice. The useful question isn't which one asserts accessibility harder, it's what evidence each publishes.

Base UI handles aria roles and attributes, pointer interactions, keyboard navigation and focus management, and its accessibility page is unusually candid about what stays with you. Quoted verbatim: "it's the developer's responsibility to visually indicate focus." On contrast it says it's important to meet the minimum requirements between foreground and background elements, and recommends APCA unless your application has stricter compliance needs.

Worth noting, because it gets repeated wrongly: Base UI does not claim WCAG 2.2 conformance anywhere on that page. It cites the WAI-ARIA Authoring Practices for keyboard patterns and links WCAG 2.2's Understanding Focus Appearance as guidance. For a headless library that's the correct scope, honestly described.

React Aria's accessibility work extends past aria roles and attributes into interaction behavior. It normalizes press, hover and focus across mouse, touch, keyboard and assistive tech, which is why its buttons don't leave sticky hover states on mobile and its menus behave identically under VoiceOver and JAWS.

Adobe also publishes its screen reader support matrix, which is the part nobody else matches. The tested combinations: VoiceOver on macOS in Safari and Chrome, VoiceOver on iOS, JAWS on Windows in Firefox and Chrome, NVDA on Windows in Firefox and Chrome, and TalkBack on Android in Chrome. Adobe additionally ships @react-aria/test-utils, currently a release candidate, with testers for 11 ARIA patterns.

Verdict: React Aria Components, on published evidence and interaction breadth. Base UI ships genuinely accessible components and they're well-built. React Aria has more surface area covered, a longer public record of testing it, and the testing tooling to let you verify your own work.

Internationalization

This is the least close section in the article.

React Aria ships 34 locale bundles covering 32 languages inside the package, from ar-AE to zh-TW. We counted them in the 1.21.1 tarball rather than taking the docs' word for it. Screen reader announcements, date formats and number formats are translated for you.

Through @internationalized/date it supports 13 calendar systems: Gregorian, Buddhist, Hebrew, Islamic, Japanese, Persian and more. RTL is handled at the interaction level, so keyboard navigation reverses direction rather than just mirroring the CSS.

Base UI ships no localized strings. Its components accept locale props typed as Intl.LocalesArgument and use Intl.Collator for locale-aware filtering, which is the right primitive-level approach, but the translations are yours to supply. Since Base UI has no date components, the calendar-system question doesn't arise for it at all. It does have a DirectionProvider for RTL.

To be fair about what this means: if your product is English-only, this section is worth nothing to you, and choosing on it would be silly. If you ship to multiple locales, it's probably the deciding factor in the whole comparison.

Verdict: React Aria Components, decisively. Adobe built this for products shipping in dozens of languages, and it shows.

Styling

Neither library ships a single line of CSS, so this is about the hooks they give you rather than the defaults they impose. Both are unstyled components in the strict sense: no reset, no theme, nothing optional to opt out of.

Base UI exposes data-* attributes on every part of its unstyled components — [data-open], [data-checked], [data-highlighted] — so state lives in CSS selectors. className accepts a function of state. Positioned popups expose CSS variables like --available-height and --anchor-width, which is exactly the geometry you can't compute in CSS yourself.

React Aria does the same things with different ergonomics. Every component takes a default class following the react-aria-ComponentName convention, so plain CSS works with no configuration. State arrives through both data attributes and render props, and Adobe ships tailwindcss-react-aria-components, a first-party Tailwind plugin at around 392,000 weekly downloads that turns data-[hovered]: into hovered:.

Verdict: a genuine tie. Base UI's popup CSS variables are a nice touch React Aria doesn't match. React Aria's first-party Tailwind plugin is a nice touch Base UI doesn't match. Both are excellent, and neither will be the reason you regret your choice.

Your styling solution matters more than you think

Both ship unstyled components and no CSS, so the styling solution you bring does all the visual work. Choose it deliberately, not from a template.

• Tailwind CSS: the most common choice among developers here, and the one with the most first-party support. It works with both without ceremony, and class strings on parts are the dominant pattern. Adobe ships a Tailwind CSS plugin for React Aria that turns data-[hovered]: into hovered:, and Base UI works with Tailwind CSS with no plugin, since its data attributes are standard selectors.
• CSS Modules: a pleasant fit for both. CSS Modules scoping pairs well with data-attribute state, and it keeps long class strings out of your component files.
• Plain CSS: works with both. React Aria has a small edge from its default class names, so plain CSS works before you've configured anything.
• Styled components and CSS-in-JS: supported, but weigh the runtime cost and server component friction before committing. Styled components in particular have had a hard few years in the React ecosystem since server components arrived.

Whichever styling solution you pick, check how state reaches your CSS. Base UI's [data-open], inherited from Radix primitives, and React Aria's [data-entering] are different vocabularies for the same idea, and a team using both needs to know which a file speaks.

This is where "complete control" gets its meaning. Both give you complete control over markup and appearance, and that is the product. What neither gives you is a starting point, which is why libraries built on them exist, trading some complete control for one.

Composition and component APIs

Of the two headless UI libraries, Base UI has the better design here, and it's worth being specific about why.

Base UI types its render prop as React.ReactElement | ComponentRenderFn. Hand it an element, or hand it a function when what renders depends on state. For your own render-prop components there is useRender, while mergeProps joins handlers, className and style without clobbering.

The standout piece of API design is eventDetails. Change handlers get a second argument carrying the reason, the native event, cancel(), allowPropagation(), isCanceled, isPropagationAllowed and the trigger element.

It declares exactly 35 distinct reasons, including trigger-press, outside-press, escape-key, list-navigation and swipe, each typed to the native event it can produce, so narrowing to reason: 'escape-key' gives you a KeyboardEvent. Want a popover that stays open when its trigger is pressed? Cancel that event instead of a controlled-state workaround.

React Aria's model is render props, slots and context. State passes down through context, so <Label> and <FieldError> wire themselves up inside a <TextField> without prop drilling.

It's mature and well-liked, with more than two years of public use, and its collection API handles large lists, virtualization and other complex components in ways Base UI doesn't attempt. The cost is verbosity: equivalent work takes more lines than in Base UI or Radix UI, a real tax rather than a stylistic quibble.

Verdict: Base UI, outright. eventDetails is the best primitive-level API detail in the category, and the composition model is cleaner than Radix primitives'. React Aria's is very good; Base UI's is better.

Hooks or components? The axis nobody else covers

This is a structural difference that most comparisons miss entirely, and for some teams it's the whole decision.

React Aria ships two layers. The components layer is what you'll use for most work. Underneath it sits a documented hooks layer — useSelect, useComboBox, useTable, usePress, useFocusRing and many more — that lets you rebuild the markup entirely while keeping the behavior guarantees. When a component's DOM doesn't fit your design, you drop down rather than fork.

Base UI ships one layer. Its escape hatch is the render prop, which swaps the rendered element for any part. That's elegant and covers most cases, but it's a different kind of flexibility: you're replacing the element, not rebuilding the widget.

Which you want depends on how unusual your markup needs to be. If you're implementing a conventional design system with conventional widgets, Base UI's single layer is less to learn. If you know you'll need a combobox whose DOM looks nothing like anyone's combobox, the hooks layer is the thing you'll be glad of in month four.

Verdict: React Aria, for teams building something unusual. A second, lower layer is optionality you don't pay for until you use it.

State management and controlled components

Both handle state management the same way in outline and differently in detail, and it's where custom design systems get awkward.

Every interactive component in both is uncontrolled by default with a controlled escape hatch, the convention across headless UI libraries generally. A Select manages its own open state until you pass a value and an onChange, at which point it's yours.

React Aria splits this explicitly. The components layer wraps a separate state management layer, react-stately, holding the logic for selection, collections, dates and text. Drop to the hooks layer and you work with those state objects directly: more work, and considerably more power on complex components.

Base UI keeps state inside the components themselves, and eventDetails is how you influence it. Rather than lifting state to work around a behavior, you cancel the event that would have caused it, which is a genuine improvement on how Radix primitives handled the same situations.

For developers: if a lot of state is shared across components, React Aria's separated state layer gives you somewhere to put it. If your components are mostly independent, Base UI's model is less machinery.

Animation and transitions

Both solve the hard problem here, which is exit animations, meaning keeping an element mounted long enough to animate out.

Base UI exposes [data-starting-style] and [data-ending-style], so an enter and exit transition is a few lines of plain CSS with no animation library. Its docs recommend transitions over keyframe animations for a specific and correct reason, quoted verbatim: "transitions are recommended over CSS animations, because a transition can be smoothly canceled midway." A popup closed before it finishes opening animates gracefully rather than snapping.

React Aria exposes isEntering and isExiting as render-prop state, with matching [data-entering] and [data-exiting] selectors. With the Tailwind plugin those become entering: and exiting: variants.

Verdict: a tie, with a slight edge to Base UI on documentation. Both give you the same capability. Base UI's explanation of why transitions beat keyframes is the better piece of teaching.

Forms and validation

Base UI extends the native constraint validation API. Field and Form build on browser validity rather than replacing it, and there are documented integrations for React Hook Form and TanStack Form.

React Aria does the same thing with a slightly wider surface: client-side constraint validation props, custom validation functions, and server validation support, so a server error renders through the same FieldError component as a client-side one. Every component built on it inherits that.

Verdict: a tie, with different emphases. Base UI leans on the platform and integrates outward; React Aria covers the server-validation round trip in the box.

Bundle size and dependencies

Base UI is the smaller install on paper: five runtime dependencies against React Aria's seven, all first-party on both sides, and 9.18 MB unpacked against React Aria Components' 6.6 MB across 1,431 files.

But you'll see React Aria's bundle size used against it in comparisons, usually as a large figure for the whole package set against a single Radix or Base UI primitive. That comparison is misleading and worth correcting, because both libraries tree-shake and you import per component. A real app pulls a fraction of either library.

Compare like for like: one component tree against one component tree, measured in your own build, with your own bundler. Anything else is a headline, not a measurement.

The honest structural difference is that React Aria carries more because it does more. Date components need @internationalized/date. Localized announcements need 34 locale bundles. If you don't ship dates and you don't ship in other languages, you're carrying capability you won't use, and Base UI's smaller surface is a real advantage.

Verdict: Base UI on absolute footprint, with the caveat that it's smaller partly because it does less.

Ecosystem, governance and long-term support

Base UI's reach comes through shadcn/ui, which is the largest distribution channel in the React ecosystem for this kind of code. Being the default base since July 2026 means an enormous amount of Base UI code is being generated, copied and published right now. If you want the biggest pool of examples and the highest chance an AI agent produces working code on the first try, that's a real advantage.

React Aria's reach comes through Adobe. It's Apache-2.0, it's been stable since December 2023, and Adobe's own products depend on it, which is the strongest possible signal that it will still be maintained in five years. Its downstream component libraries include our own Untitled UI React and HeroUI, and shadcn/ui added it as a first-class base in July 2026, so npx shadcn@latest init --base aria gets you React Aria underneath.

Worth thinking about for a five-year design system: the incentive structures differ. Base UI is staffed by a commercial business that also sells MUI X. React Aria is funded by Adobe because Adobe's products need it. Neither is a red flag, but they're different kinds of bet, and bus factor is a legitimate selection criterion that no other comparison treats as one.

Verdict: Base UI on current reach, React Aria on longevity signals. Pick your risk: a young library with enormous adoption, or a mature one with a very large company depending on it.

Is Radix UI dead?

No, and it's worth answering directly because it's the anxious subtext of every search in this space.

Existing Radix projects need no migration, and initializing a shadcn project with -b radix still works. The shadcn/ui changelog is blunt about it: 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)."

What changed is defaults and momentum, not support for Radix UI. New projects get Base UI unless they ask otherwise, and the attention of the people who originally built Radix has moved to Base UI. If you're already on Radix and it's working, there's no urgency. If you're choosing today, these two are where the work is going.

Can you use both?

You can, and there are reasonable cases for it. You're on Base UI through shadcn/ui and you need a date picker, or a data table, or a color picker, and building one is not a good use of three weeks.

Two things to watch:

• You'll ship both runtimes. That's five packages plus React Aria's seven. Not enormous, but real, so scope the second library to the components that need it rather than drifting into using both everywhere.
• The state and styling conventions differ. Base UI's [data-open] and React Aria's [data-entering] live in different vocabularies, and your CSS will need to know which component it's styling. Keep them in separate directories so it's obvious at a glance.

If you're on shadcn/ui specifically, there's a cleaner option: initialize with --base aria and get React Aria implementations of the shadcn components, rather than running two primitive layers side by side.

What this means for developers, day to day

Here's what developers notice after two weeks in each, and where developer experience diverges.

Base UI, in practice:

• Fewer lines for the same result, and developers coming from Radix primitives are productive immediately, because the mental model is the same.
• eventDetails turns a category of workarounds into a one-liner, and it's the detail developers cite most when they say the API design is better.
• Smaller surface to learn: one layer, thirty-seven components, consistent parts.
• A predictable developer experience. When a component doesn't do what you need, the render prop is the answer. When render isn't enough, you're writing it yourself.

React Aria, in practice:

• More verbose. Equivalent work takes more lines, and that's a real tax rather than a stylistic complaint.
• Far more in the box. Dates, colors, tables, trees and drag and drop are complex components that would otherwise be quarters of work for your team.
• Two layers. When the components layer doesn't fit, the hooks layer rebuilds the markup and keeps the behavior, the escape hatch that matters on unusual user interfaces.
• Internationalization that's already done, and not a thing you retrofit cheaply.

On developer experience, Base UI is nicer to write and React Aria is nicer to have. Both beat building these components yourself. Teams building conventional user interfaces prefer the first; teams building custom design systems with unusual requirements end up glad of the second.

One hard constraint in the React ecosystem: Base UI requires React 17 or later, and works on 17, 18 and 19, which matters if you're maintaining something older.

Most developers don't want to build a design system, they want to ship product. That's what libraries built on these primitives are for: Untitled UI React and HeroUI on React Aria, shadcn/ui on Base UI. Choosing between headless libraries only makes sense if the design work is yours.

Conclusion

Base UI and React Aria Components are both excellent headless libraries, and most teams will succeed with either. The choice comes down to two questions.

Do you need dates, colors, tables or trees? If yes, React Aria Components. Those are among the hardest categories in UI engineering, they take months to build properly, and Base UI doesn't ship them.

Do you ship in more than one language? If yes, React Aria again. 34 locale bundles and 13 calendar systems in the box is not something you replicate on a deadline.

If both answers are no, and you're building English-language user interfaces out of menus, dialogs, popovers and form controls from unstyled components, Base UI is the better headless component library. Cleaner API, smaller dependency graph, MIT, React 17 support, and shadcn/ui's default, which means the largest pool of working examples in the React ecosystem.

A simple mental model:

• Need a date picker, calendar or time field? Pick React Aria Components.
• Need a data table, tree or list with selection? Pick React Aria Components.
• Need color pickers? Pick React Aria Components.
• Shipping in multiple languages, or with RTL? Pick React Aria Components.
• Need a menubar, navigation menu, drawer, scroll area or OTP field? Pick Base UI.
• Already on shadcn/ui and happy with it? You're on Base UI. Stay there.
• Care most about API elegance and the smallest dependency graph? Pick Base UI.
• Need to support React 17 or 18? Pick Base UI.
• Want the behavior layer without doing the design work at all? That's what libraries built on these are for: Untitled UI React on React Aria, or shadcn/ui on Base UI.

Whatever you choose, build one real component with each before you commit. An afternoon with a Select tells you more than any comparison table, including this one.

We'll be updating this post as both libraries evolve. For a wider view, see our roundup of the best React UI component libraries in 2026, Untitled UI React vs. Base UI, and Untitled UI React vs. React Aria Components.

Also relevant: our comparison of Untitled UI React and shadcn/ui, the best shadcn/ui alternatives, the best Tailwind Plus alternatives, React dashboard templates, the best component libraries for vibe coding, and our guide to what a design system actually is.