Radix UI

What Is Radix UI?

Radix UI is a library of unstyled, accessible React component primitives for building high-quality design systems and web applications. The short, answer-first definition is this: Radix gives you the behavior, accessibility, and interaction patterns of complex UI components, dialogs, dropdown menus, popovers, tooltips, tabs, accordions, and many more, without any visual styling, so your team supplies the look using whatever approach you prefer (CSS, Tailwind, CSS-in-JS, or anything else). It is a code-level React dependency, distributed as a set of @radix-ui/react-* packages, that handles the genuinely hard parts of UI engineering while leaving design decisions entirely in your hands.

The word "primitive" captures the philosophy. Radix does not ship a finished, branded component kit. Instead it ships low-level, composable building blocks that each solve one interaction problem correctly, focus management, keyboard navigation, screen-reader announcements, collision-aware positioning, dismissal behavior, and you assemble and style them into the components your design system needs. This makes Radix a foundation rather than a finished product, which is exactly why it has become the engine underneath many modern design systems and popular higher-level toolkits.

Radix UI rose to prominence as the accessibility-and-behavior backbone of the React ecosystem, and it is notably the primitive layer that the widely used shadcn/ui collection is built on. Precise, current market-share percentages are difficult to state with confidence, because Radix is unstyled and frequently embedded inside other libraries and bespoke design systems, and detection methodologies differ, so treat any single headline figure cautiously. What is clear qualitatively, and reflected in its large following and its role under shadcn/ui, is that Radix is one of the most influential and widely adopted accessibility-first primitive libraries in modern React development.

It is important to be clear about what Radix UI is not. It is not a browser extension, not a no-code tool, and not a styled component library you drop in for an instant look. It is an unstyled, behavior-and-accessibility layer. StackOptic classifies it under UI component libraries, with the same nuance that applies to all headless libraries: because Radix adds little to no visible styling, it is detected through specific data attributes rather than branded class names, and a non-detection is more often inconclusive than definitive.

How Radix UI Works

Radix UI provides a set of primitives, each delivered as its own package (for example @radix-ui/react-dialog, @radix-ui/react-dropdown-menu, @radix-ui/react-popover, @radix-ui/react-tooltip, @radix-ui/react-accordion, @radix-ui/react-tabs). You import a primitive and compose it from its constituent parts. A dialog, for instance, is built from Dialog.Root, Dialog.Trigger, Dialog.Portal, Dialog.Overlay, Dialog.Content, Dialog.Title, and Dialog.Close. Each part is a real element you can style and arrange independently, which is the heart of Radix's composition model: granular control over structure and appearance, with correct behavior guaranteed underneath.

What Radix handles for you is the difficult, error-prone substance of interactive components. The dialog primitive manages a focus trap and restores focus on close. The dropdown menu supports full keyboard navigation with typeahead and roving focus. The popover and tooltip handle collision-aware positioning so they flip and shift to stay within the viewport, along with screen-reader announcements and dismissal on escape or outside click. All of this follows WAI-ARIA authoring practices and works automatically, so teams get accessible, robust behavior without re-implementing it for every project.

Because Radix is unstyled, it does not load a stylesheet or impose any appearance. You apply your own styles to each part using any method: plain CSS or CSS modules, Tailwind utility classes, or a CSS-in-JS library. This is why Radix is so often the base layer for higher-level toolkits, shadcn/ui, for example, takes Radix primitives and adds Tailwind styling and sensible defaults on top, giving developers copy-paste components that are accessible by virtue of Radix underneath.

A defining technical detail, and the key to detection, is how Radix wires up its behavior in the DOM. Radix primitives render elements carrying data-radix-* attributes and data-state attributes that reflect both their identity and their current interaction state. An open dropdown content element might carry data-state="open"; a closed one data-state="closed". Trigger and content elements are linked through generated id and aria-* attributes, and portalled content (dialogs, popovers, dropdown menus) is rendered into a container often marked with attributes like data-radix-portal near the end of the <body>. Radix also relies on aria-controls, aria-expanded, and similar attributes whose values often reference Radix-generated IDs.

The result is a clean separation: Radix owns behavior, accessibility, and the structural data attributes; your styling layer owns appearance. That separation makes Radix superb for building bespoke, accessible design systems, and it also means the library's fingerprint lives in data attributes rather than in a visible class prefix.

How to Tell if a Website Uses Radix UI

Detecting Radix UI relies on its characteristic data attributes rather than branded class names, because the library is unstyled and the visible classes on the page typically come from the project's own styling (often Tailwind, especially when shadcn/ui is in use). StackOptic inspects these signals from the server side by parsing the page, and you can confirm them by hand. As with every headless React library, treat a missing signal as inconclusive: the most telling attributes often appear only on opened, interactive components.

• data-radix-* attributes. This is the strongest and most specific tell. Radix primitives and their portals render elements carrying attributes that begin data-radix-, for example a portal/positioning wrapper marked with data-radix-popper-content-wrapper, or other data-radix--prefixed hooks on collection and focus-scope elements. Finding any data-radix- attribute in the DOM is close to definitive proof of Radix UI.
• data-state attributes. Radix components expose their open/closed and active/inactive status through data-state attributes with values like open, closed, active, inactive, on, off, checked, and unchecked. A data-state="open" on a dialog, dropdown, or accordion panel is a classic Radix signal. Note that data-state is also used by some other libraries, so it is most convincing alongside a data-radix- attribute.
• Portalled overlay containers. Dialogs, popovers, dropdown menus, and tooltips render into portal containers appended toward the end of the <body>. A trailing wrapper such as data-radix-popper-content-wrapper (used for collision-aware positioned content) is a recognizable structural hint.
• Generated IDs and ARIA wiring. Radix links triggers and content with generated ids referenced by aria-controls, aria-labelledby, and aria-describedby, and applies aria-expanded/aria-haspopup on triggers. Correct, complete ARIA wiring around a custom widget reinforces a match.
• Radix class hints and bundle markers. Some setups (including Radix's own styled components and certain integrations) use radix--related class hints, and in the Network tab or bundle you may see @radix-ui/react-* package references when chunks are readable. These confirm the dependency directly.
• React pairing. Radix UI is a React-only library, so a confident detection should coincide with React being present. Confirm via the React DevTools extension or framework hints in the bundle, as covered in how to check if a website uses React, Vue, or Angular.

Here is how to verify each signal yourself:

Method	What to do	What Radix UI reveals
View Source	Open the page and view source	data-radix-* and data-state attributes in server-rendered HTML, if present
DevTools Elements	Inspect a dialog, dropdown, tooltip, or accordion	data-state="open"/"closed" and data-radix--prefixed wrappers on the parts
DevTools (interaction)	Open the menu/dialog and watch the DOM	A data-radix-popper-content-wrapper portal appended near the end of <body>
DevTools Network	Filter the bundle for radix	@radix-ui/react-* references when source maps or chunks are readable
Wappalyzer	Run the browser extension on the page	May flag Radix UI, though unstyled libraries are detected less reliably

A quick command-line check is curl -s https://example.com | grep -o 'data-radix-[a-z-]*' | sort -u to surface Radix-specific attributes, and grep -o 'data-state="[a-z]*"' to find state markers. Two caveats matter here. First, the most distinctive attributes appear on interactive components (dialogs, dropdowns, popovers) that may only render after a user opens them, so a static fetch frequently misses them; inspecting the live page after interacting is the reliable route. Second, like all React libraries, a client-rendered app may serve sparse initial HTML, so the attributes appear only after hydration. For the broader methodology, see how to find out what technology a website uses and how to check what JavaScript libraries a website uses.

Key Features

• Unstyled, composable primitives. A broad set, Accordion, Alert Dialog, Aspect Ratio, Avatar, Checkbox, Collapsible, Context Menu, Dialog, Dropdown Menu, Hover Card, Label, Menubar, Navigation Menu, Popover, Progress, Radio Group, Scroll Area, Select, Separator, Slider, Switch, Tabs, Toast, Toggle, Toggle Group, and Tooltip, each exposing its parts for independent styling.
• Accessibility by default. WAI-ARIA-compliant behavior including focus trapping and restoration, keyboard navigation, typeahead, screen-reader announcements, and dismissal handling.
• Collision-aware positioning. Popovers, tooltips, and menus automatically flip and shift to stay within the viewport, via a built-in positioning layer.
• State-driven styling hooks. data-state and other data attributes expose interaction state so you can style each state with your own CSS or utilities.
• Composition model. Components are split into named parts (Root, Trigger, Content, and so on) for granular structural and visual control.
• Styling-agnostic. Works with plain CSS, CSS modules, Tailwind, or CSS-in-JS, and serves as the foundation for higher-level toolkits like shadcn/ui.

Pros and Cons

Pros

• Best-in-class accessibility and behavior for complex widgets, handled automatically and rigorously.
• Complete styling freedom: you control appearance entirely while relying on correct underlying behavior.
• A broad, granular primitive set with a composition model that scales into full, bespoke design systems.
• The de facto foundation for popular toolkits (notably shadcn/ui), with a large, active ecosystem.

Cons

• Unstyled by design, so it requires real styling effort and is not a fast path to a finished look on its own.
• React-only, with no first-party Vue or Angular support, unlike some headless alternatives.
• The composition model and per-part styling have a learning curve compared with drop-in styled components.
• Being unstyled and attribute-based, it is harder to detect and to recognize in someone else's codebase.

Radix UI vs Alternatives

Radix UI competes with other headless/unstyled libraries and, conceptually, with fully styled component kits. The table positions it.

Library	Styling	Frameworks	Component breadth	Best for
Radix UI	Unstyled primitives (data-radix-*)	React	Broad set of primitives	Custom design systems needing many accessible primitives
Headless UI	Unstyled (Tailwind-oriented)	React, Vue	Small, focused	Tailwind projects needing accessible interactive widgets
Chakra UI	Styled (Emotion, style props)	React	Broad	Teams wanting accessible, themeable, pre-styled components
Material UI (MUI)	Styled (Emotion, Material)	React	Very broad	Apps wanting Google's Material Design
Ant Design	Styled (ant- classes)	React	Very broad, enterprise	Data-dense business apps and dashboards

The most instructive comparison is Radix UI versus Headless UI, since both are unstyled, accessibility-first libraries. Radix offers a broader catalog of primitives and a fine-grained composition model, but is React-only; Headless UI offers a smaller, focused set and supports both React and Vue, with a Tailwind-oriented design. In the DOM they are distinguished by their fingerprints: Radix shows data-radix-* and data-state attributes, while Headless UI shows headlessui- IDs and data-headlessui-state attributes. Against styled libraries like Chakra UI, Material UI, and Ant Design, the trade-off is the headless one: those deliver finished, styled components quickly, while Radix delivers behavior and accessibility and full styling control. For a direct comparison with the other major unstyled option, see Headless UI.

Use Cases

Radix UI is the natural choice for teams building a custom design system who need accessible, well-engineered component behavior without any prescribed styling. It lets them define their own visual language while relying on Radix for the focus management, keyboard interaction, and positioning that are so hard to implement correctly, producing components that are both on-brand and genuinely accessible.

It also underpins higher-level toolkits and product UIs. Teams using shadcn/ui are using Radix under the hood, getting copy-paste, Tailwind-styled components whose accessibility comes from Radix. Product teams that want maximum control over appearance, but not the burden of reinventing widget behavior, adopt Radix directly. Accessibility-focused organizations choose it specifically because its primitives follow WAI-ARIA practices out of the box, reducing the risk of shipping inaccessible custom components.

Consider a few scenarios. A company building an internal design system might wrap Radix primitives with its own styling and tokens, distributing accessible Dialog, DropdownMenu, and Tabs components to every product team. A startup might adopt shadcn/ui to move fast, unknowingly relying on Radix for the accessibility of its modals and menus. A team with strict accessibility requirements, perhaps due to regulatory obligations, might choose Radix precisely so that focus trapping, keyboard navigation, and screen-reader support are handled correctly by a well-tested library rather than hand-rolled code.

From a technology-research and lead-generation standpoint, detecting Radix UI signals a modern React stack built by a team that cares about both custom design and accessibility, and it is a strong hint that the site may be using shadcn/ui or a bespoke design system on top of Radix, frequently alongside Tailwind CSS. For vendors selling to such teams, developer tools, design-system tooling, accessibility services, that is valuable qualifying context, even though the unstyled, attribute-based nature of the library means detection is most reliable on the live, interacted-with page. Our guide on using tech-stack data to qualify leads explains how to turn signals like these into prospects.

Frequently Asked Questions

How can I tell if a website uses Radix UI?

Inspect interactive components, dialogs, dropdown menus, tooltips, accordions, in DevTools and look for data-radix-* attributes (such as a data-radix-popper-content-wrapper portal) and data-state attributes with values like open or closed that change as you interact. References to @radix-ui/react-* packages in the bundle confirm it directly. Because Radix is unstyled, the visible classes on the page usually come from the project's own styling (often Tailwind via shadcn/ui), so the data-radix- and data-state attributes are the signals that actually identify the library.

Why is Radix UI hard to detect from the page source alone?

Two reasons. First, Radix is unstyled and attribute-based, so it does not add a branded class prefix to every element; its fingerprint lives in data-radix-* and data-state attributes rather than visible class names. Second, the most distinctive attributes appear on interactive components, dialogs, dropdowns, popovers, that often render into a portal only after a user opens them, so a static fetch of the page frequently misses them. Inspecting the live page after interacting with its menus and dialogs is the reliable approach.

Is Radix UI the same as shadcn/ui?

No, but they are closely related. Radix UI is the unstyled primitive library that provides behavior and accessibility. shadcn/ui is a collection of copy-paste React components that are built on top of Radix primitives and styled with Tailwind CSS. In other words, a site using shadcn/ui is using Radix underneath, which is why you will often find data-radix-* and data-state attributes on shadcn/ui components. shadcn/ui adds the styling and defaults; Radix supplies the accessible behavior beneath.

Does Radix UI work with Vue or Angular?

The first-party Radix UI primitives are built specifically for React, distributed as @radix-ui/react-* packages, so they require React to run. There is no official Vue or Angular version of Radix itself, though community projects have ported the ideas to other frameworks under different names. If you need an unstyled, accessible component library with official Vue support, Headless UI is the more direct option. For detection purposes, a genuine Radix site will be a React application, so confirming React alongside the data-radix- attributes gives the most confident result.

What is the difference between Radix UI and Headless UI?

Both are unstyled, accessibility-first libraries, so the differences are scope, framework support, and ecosystem. Radix offers a broad set of primitives with a fine-grained composition model and is React-only; it is the foundation under shadcn/ui. Headless UI offers a smaller, focused set, supports both React and Vue, and is oriented around Tailwind CSS. They also leave different fingerprints: Radix shows data-radix-* and data-state attributes, while Headless UI shows headlessui- IDs and data-headlessui-state attributes, which is how you tell them apart when auditing a site.

Want to detect Radix UI and the full stack behind any site in seconds? Try StackOptic at https://stackoptic.com.