shadcn/ui stopped being a component library the moment it shipped a registry format. What it is now is a distribution mechanism: any project can publish a registry.json, and npx shadcn add will fetch from it exactly the way it fetches from the official one. That is why there are hundreds of registries and why the useful question is no longer "which library" but "which registries are worth adding to this project".
The directory tracks the ones that publish an index, with what each holds, its repository, its stars, when it last shipped and how many of its components are already here. This is the shape of that landscape.
The three kinds of registry
Motion and marketing. Animated heroes, backgrounds, buttons and text effects, built for landing pages. Magic UI is the largest at 247 indexed components and 22,000 stars; Aceternity's index carries 278; Kokonut UI, Cult UI and Eldora sit in the same family. These are where a launch page gets its personality, and they are thin on anything a product runs on.
General and product. Broader sets aimed at application UI: forms, tables, dialogs, settings. ReUI indexes 1,607 items and Tailark 468, both an order of magnitude larger than the motion registries, because product surfaces need more parts.
Single-purpose. One idea, done properly: a map registry, a loaders registry, a hooks registry, an editor. These are the ones worth knowing about precisely because they are invisible in a star ranking.
What actually decides whether to add one
When it last shipped. The single most useful column, and the one no star count reflects. A registry with 6,000 stars and no commit since March is a snapshot, not a dependency. One with 2,000 stars and a commit yesterday is being looked after.
Whether the code is yours after install. This is the whole point of the shadcn model: add copies files into your repo. There is no version to bump and no upstream to break you, and equally no upstream fix arriving on its own. Treat an installed component as your code from that moment.
What it drags in. A registry item can declare npm dependencies and other registry items. One card component can pull an animation runtime, an icon set and three primitives. The dependency list on the component page is the thing to read before the preview.
Whether it collides with what you have. add writes to components/ui, and two registries with a button.tsx will overwrite each other. Namespaced install paths, or a review of every file the command touches, is what stops a silent regression across your app.
Using more than one
The setup most projects converge on is three layers, and it is worth being deliberate about them.
shadcn/ui for primitives, because everything else assumes them. One general registry for product components, so the forms and tables share a look. And individual components from anywhere for the pieces that are meant to stand out, taken one at a time rather than by adopting a whole library.
The failure mode is adopting three motion registries and ending up with four different button implementations, three animation runtimes and a bundle nobody can explain.
Publishing your own
A registry is a JSON file and a set of source files. registry.json lists items; each item has a name, a type, its files, its npm dependencies and its registry dependencies. Build it, host it anywhere static, and npx shadcn add https://your-site.com/r/thing.json works.
Two things make the difference between a registry people install from and one they bounce off. Every item needs its dependencies declared honestly, because an install that fails on a missing import is an install nobody retries. And each item wants a demo, because a name and a file list are not enough to decide from - which is the argument for publishing to a catalogue that renders a live preview beside the code.
Where else to look
The honest list, because the answer is not always us:
| Source | Best for | Trade-off |
|---|---|---|
| shadcn/ui | The primitives and the registry format itself | Deliberately small; no blocks or motion |
| The registries' own sites | Docs, the author's framing, anything unreleased | One site per registry, and no way to compare |
| The directory on 21st | Size, stars, last commit and what is already previewable | Only registries that publish an index |
| 21st libraries | The same view for libraries hosted here | A subset of the wider landscape |
Taking one
Every component page has a live preview and the code. Installing goes through the shadcn CLI against our registry:
That key comes from your 21st account, and installs require a membership. Set API_KEY_21ST once in your shell and the command works for anything in the catalogue. The 21st MCP covers the same ground without leaving the editor: ask Claude, Cursor or Codex for a component, get the previews inline, and let the agent write the file.
Browse the registry directory →
Frequently asked
- What is a shadcn registry?
- A JSON index plus a set of source files, hosted anywhere static. Each item names its files, its npm dependencies and any other registry items it needs, and npx shadcn add fetches from it exactly the way it fetches from the official registry. That format is why there are hundreds of them rather than one library.
- How do you decide whether to add a registry?
- Check when it last shipped, which no star count reflects; check what an item drags in, since one card can pull an animation runtime and three primitives; and check whether its file names collide with what you already have, because add writes into components/ui and two registries with a button will overwrite each other.
- Can you use several registries at once?
- Yes, and most projects end up with three layers: shadcn/ui for primitives, one general registry for product surfaces so forms and tables share a look, and individual components from anywhere for the pieces meant to stand out. The failure mode is adopting three motion registries and ending up with four button implementations.
- How do you publish your own registry?
- Write a registry.json listing your items, each with a name, a type, its files and its dependencies, build it, and host it as static files. Two things decide whether people install from it: honest dependency declarations, because an install that fails on a missing import is never retried, and a demo per item, because a file list is not enough to choose from.