Below the well-known registries there is a long tail: Skiper UI, Eldora UI, Sera UI and a few dozen others, each with somewhere between fifty and a few hundred items. They are worth knowing about for one reason and worth being careful with for another, and both come from the same fact - they are usually one person's work.
What the tail is good for
One component you cannot find anywhere else. The large registries converge on the same set, because they are all serving the same demand. The interesting components - an unusual interaction, a specific effect, a niche layout - are disproportionately in the small ones.
A different aesthetic. Each small registry is one designer's taste, undiluted. That is exactly what you want when the big registries all look related to each other.
Reading the source. A fifty-item registry is a set you can actually look through, and often the best way to learn a technique is to read one careful implementation of it.
What to check, and it is short
When it last shipped. The single most useful column, and the tail is where it varies most: Eldora's repository last shipped in March, which does not make its components worse but does mean nothing new is coming. Because add copies source, an abandoned registry's components keep working; what stops is fixes.
Whether the item declares its dependencies. The most common defect in a small registry, and the one that turns an install into a debugging session. The publishing guide makes the same point from the author's side.
Whether it reads your tokens. A component hardcoding bg-zinc-900 looks right in its own screenshot and wrong in your theme.
Whether the name collides. A registry shipping button.tsx will overwrite yours, which the CLI guide covers.
How to use the tail sensibly
Take components, not registries. The layered setup - shadcn for primitives, one general registry for product surfaces, individual components for the pieces meant to stand out - means a small registry contributes one or two components rather than a dependency.
That framing also removes the maintenance worry. A component you took, read and adapted is your file. Whether its origin ships again next month is a question about future components, not about the one in your repository.
The directory is the fastest way to see the tail with the facts attached - size, stars, last commit - rather than through whichever one was in a newsletter.
Where else to look
The honest list, because the answer is not always us:
| Source | Best for | Trade-off |
|---|---|---|
| The registry directory | Seeing the whole tail with last-commit dates | Only registries that publish an index |
| A single small registry | One aesthetic, undiluted, and unusual components | Usually one person, and it can go quiet |
| The large registries | Coverage and maintenance | They converge on the same set |
| 21st | Individual components from across all of them, with previews | Quality varies by author, so preview before you take it |
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.
Browse the registry directory →
Frequently asked
- Are small component registries worth using?
- For individual components, yes. The large registries converge on the same set because they serve the same demand, so the unusual interactions and specific effects are disproportionately in the small ones. Each is also one designer's taste undiluted, which is what you want when the big ones look related.
- What if a small registry stops being maintained?
- Your installed components keep working, because add copies source rather than linking to it. What stops is future fixes and new components. That is why the useful framing is to take components rather than adopt registries: a component you read and adapted is your file.
- What should you check in a small registry?
- When it last shipped, which the directory shows and star counts do not. Whether items declare their dependencies, the most common defect and the one that turns an install into debugging. Whether components read your tokens rather than hardcoding colours. And whether file names will collide with yours.
- How do you find registries beyond the well-known ones?
- The directory lists every tracked registry with its size, stars and last commit, which is a faster way to see the tail than following whichever one appeared in a newsletter. Browsing by what you need rather than by name is what surfaces the small ones at all.



