How the index is built

1. Finding the registries

There is no directory of shadcn registries to read — which is most of the reason this product exists. The corpus is assembled from four independent angles and deduplicated by host:

• Seeds. The registries everyone already knows, asserted by name so they cannot be missing on day one. They are then verified like everything else — a seed that no longer serves a valid manifest is dropped, not published on the strength of being famous.
• GitHub code search for registry.json, from four different angles because the search API caps at 1,000 results per query no matter what its own total_count claims.
• GitHub topics — the repositories that tag themselves as registries but keep the manifest somewhere a path filter misses.
• The ecosystem’s awesome-list, mined for both its GitHub links and its plain site links. The second kind matters more: a registry that publishes a site and no source is invisible to code search and turns up nowhere else.

Roughly two thirds of everything found this way never reaches the index. registry.json is a common filename, and early runs pulled in a Terraform module registry and a Docker config before the check tightened.

2. Deciding what counts as a registry

A candidate has to serve JSON that parses and whose items look like registry items — at least half of them carrying a type that starts with registry:. Deliberately not the $schema key: plenty of real registries omit it, while nothing else in the world publishes an array of objects typed that way.

Three manifest shapes are accepted, because all three are real and installable: the current { name, homepage, items: [] } standard, the bare array shadcn itself still serves at /r/index.json, and the older { registry: [] } wrapper.

The live site is tried before the repository, on purpose. A manifest that exists in git but is not served is a registry nobody can install from, and indexing it would produce install commands that fail. Where only the repository copy exists, the registry is published and labelled repo only.

3. Free or paid

This is the question every visitor actually has, and it is the one most directories answer by reading a pricing page once. Here the crawler fetches each registry’s item endpoint — the exact URL npx shadcn@latest add would fetch. If the source comes back, the item is free. If the endpoint answers 401, it is paid. That is the same request the install makes, so the answer cannot drift from reality without the install drifting too.

Registries that serve no probeable item endpoint have their items marked unverified, never free. Several registries are mixed: a fully public, browsable manifest with the item endpoints gated. That case is invisible until you try to install, which is exactly why it is labelled.

The URL shape is learned once per registry from two sample items and then applied to all of them — on a 250-item registry that is three probes instead of 750.

4. What a preview actually is

A registry item is somebody else’s React and Tailwind. Executing it here would not be faithful even if it were safe: a component’s theme tokens, fonts and Tailwind config are what make it look like itself, and none of that travels with the source file.

So a live preview is the registry’s own rendered demo page, framed. When that works you are looking at the component actually running, maintained by the people who wrote it, and it can never go stale relative to the source. Most sites refuse to be framed, so the crawl reads each registry’s X-Frame-Options and CSP frame-ancestors headers and records the answer — a frame is only ever mounted for a registry that will render one. 17,966 items qualify.

Everything else shows the component’s real markup, as its registry serves it. That is a fallback, not a picture of one — there are no screenshots anywhere on this site.

5. Noticing when something disappears

An item missing from a manifest that parsed is definitively gone: the registry served its inventory and this component was not on it. It is marked removed with a date, and its page stays up saying so — because somewhere a tutorial still tells people to install it, and landing on a page that explains the removal beats landing on a 404.

A registry that fails to answer once is a flaky host, not a dead registry. Three consecutive days of silence is the line: long enough to ride out a bad night, short enough that a shut-down registry does not sit here for a week claiming to be installable.

What this index does not do

• No quality judgement. Nothing here measures whether a component is well built, accessible or well designed. A crawler cannot establish any of that, and a number that pretends otherwise is worse than no number.
• No submissions and no edits. There is no form, and no row can be corrected by hand. A hand-editable row would make every other row unverifiable.
• No mirroring. Install commands and item URLs point at the registry’s own endpoints. Serving someone else’s component source from this origin would make this a mirror, and a stale one.
• No licence interpretation. The licence shown is the one the GitHub repository declares. Free to install is not the same as free to use commercially, and that is a question for the registry, not for us.

Where it is wrong

Registries behind aggressive bot protection answer 429 to a crawler and are reached through their repository instead, or missed entirely. Item source is capped at the first 150 items per registry, so a very large registry has pages that carry metadata and an install command but no markup. Descriptions are whatever the registry publishes, and many publish none — those rows say so rather than inventing a sentence about somebody else’s component.

Read it yourself

The whole index is an open API: no key, no account, CORS open to everyone. The same call every page here makes is the one you can make.

1curl "https://blockdex.kynth.studio/api/search?q=marquee&access=free"
2curl "https://blockdex.kynth.studio/api/registries"
3curl "https://blockdex.kynth.studio/api/stats"