soundcn: UI sound effects you paste into your codebase rather than depend on

The problem it names is asset plumbing, not audio

The stated problem is deliberately small and practical. Adding sound to web interfaces is tedious, and the readme lists the four ways it goes wrong: you hunt for free samples, you deal with licensing, you wire up audio loading, or you pull in heavy libraries, all for a simple button click sound. Each of those is a different kind of friction, and the last one is the one most developers hit hardest, because a sound library that ships an audio player weighs far more than the sound itself. The framing matters for judging the project, because it means the goal is not to be a better audio system but to remove the steps between deciding on a click and having it play. The registry that answers it holds 700 or more short sound effects, covering clicks, notifications, transitions and game sounds, and the claim is that any of them can be added to a React project with a single command. The reference site is at soundcn.xyz, and the description calls the collection curated, which in this context means the selection and the licensing have been checked rather than the waveforms being original.

One command, and the file lands in your source tree

The installation path is the shadcn CLI, which is the mechanism that shapes the whole design. A sound is added with a single command naming the sound:

npx shadcn add @soundcn/click-soft

The important detail is what that command does. The sound is not fetched at runtime and it is not installed as a dependency; it is installed directly into your codebase. The registry entry copies the .ts file and the useSound hook into your project, and the two import paths in the usage example show where they land, with the hook under a hooks directory and the sound under a sounds directory:

import { useSound } from "@/hooks/use-sound";
import { clickSoftSound } from "@/sounds/click-soft";

const [play] = useSound(clickSoftSound);

That has three consequences that matter for a production application. There is no runtime fetching, so the sound is available on first paint with no network request. There are no CORS issues, because there is no cross-origin request at all. And because the code is in your repository, it goes through your own review, your own bundler and your own version control, which means a sound is as reviewable as any other module. The trade is that the sounds are now files in your tree, so removing or replacing one is a code change rather than a version bump, and the repository size grows by the size of the base64 payloads you take.

Inline base64 means no asset pipeline at all

The technical decision that makes the single-file installation possible is that each sound is a self-contained TypeScript module with an inline base64 data URI, and the hook for playback uses the Web Audio API with zero dependencies. A base64 data URI is the audio encoded as text inside the module, which means the sound is a string in a TypeScript file rather than an asset the build has to know about. The alternative, a separate .mp3 or .wav file referenced by URL, would require the bundler to handle the asset, would need the file to be deployed alongside the JavaScript, and in the case of a sound hosted on a CDN would need CORS to work. The documented advantages are exactly the absence of those three problems, no external files, no runtime fetching, and no CORS issues. The cost is size. Base64 encoding inflates the payload by roughly a third over the raw bytes, and the encoded text is not compressed as well as a binary asset would be, so a project that installs a dozen of these is carrying a few hundred kilobytes of strings in its JavaScript bundle. For a short click that is not a concern. For a project that installs every transition and notification sound, the bundle cost is worth measuring rather than assuming.

The registry is a data file and the scripts show how it is built

The repository is a Next.js application with a registry directory and a registry.json at the root, and the package scripts show the pipeline that produces it. The registry build command is the shadcn build tool, which is the standard way a shadcn-compatible registry is compiled. The enrichment script runs a TypeScript file that adds metadata to the registry entries, and there are separate scripts for encoding all sounds and for encoding a single one, which is how the base64 data URIs get into the .ts modules in the first place. There is a script to update the registry itself, and one named for fetching the World of Warcraft head sounds, which is the acquisition step for the one collection that is not freely licensed. The site itself is built with Next 16 and the dev script uses turbopack, the site uses React 19, and the component layer is built on Radix primitives and Base UI with a set of supporting libraries for forms, charts, carousels, drawers, day pickers and toasts, plus a zustand-style atom library and nuqs for URL state. Linting is handled by biome, with an eslint config also present, and there are agent instruction directories in the repository root alongside a components.json file, which is the shadcn configuration.

The licensing split is the thing to read carefully

Most sounds are sourced from CC0 licensed collections, primarily Kenney, and the project is MIT licensed as a whole. The exception is spelled out in detail and it is not a small one. The World of Warcraft collection is 110 sounds, and those assets are the property of Blizzard Entertainment, are not CC0 and are not freely licensed. The project states that soundcn is not affiliated with or endorsed by Blizzard, that World of Warcraft is a registered trademark of Blizzard, and that these sounds are included for non-commercial, educational and reference purposes only. That is an unusually clear statement for a project that includes them at all, and it is also a restrictive one. If you install a sound from that collection into a commercial application, you are using assets the project itself says are only included for non-commercial purposes. The practical rule that follows is simple: check the collection for each sound before you ship it, and prefer the CC0 sounds for anything that goes to production. The licensing is not a footnote here, it is the main legal fact about the library, and the readme is to be credited for putting it near the top rather than in a separate licence file.

A project you browse rather than depend on

It is worth being clear about what soundcn is not. It is not a runtime dependency and not a package you add to your package.json. It is a registry, a website you browse, and a set of files you copy in. The distinction has consequences for how a team manages it. There is no version to upgrade, so an upgrade is a deliberate re-copy of a sound, and the diff shows up in review. There is no bundle to deduplicate, because there is no dependency. And the licensing has to be tracked per asset, in your own repository, because nothing enforces it for you. The readme also carries a sponsor section, with a single sponsor listed, which is worth noting because a curated sound library has real ongoing cost, since someone has to check licences, encode files and keep the registry current. The repository is MIT licensed with a LICENSE file, the last push was on 2026-06-09, and the package itself is marked private and versioned at 0.1.0, which is consistent with the package being the website application rather than the sounds.

Editorial conclusion

soundcn is a good fit for a frontend team that wants a small set of interface sounds without wiring an asset pipeline, and that prefers code you own over a package you fetch at runtime, since each sound lands as a TypeScript file in the project and the hook has zero dependencies. It is the wrong choice for a project that needs a large, parameterised audio system, and it is the wrong choice for any commercial product that plays the World of Warcraft collection, since those 110 assets remain the property of Blizzard and are included for non-commercial, educational and reference purposes only. Before shipping anything, check which collection each sound came from, because most of the library is CC0 and sourced from Kenney while the Warcraft set is not, and keep the attribution trail with the asset. The project is MIT licensed, the last push was on 2026-06-09, and the repository publishes no GitHub releases.

Frequently asked questions

Official sources

1. Issues
2. kapishdima/soundcn on GitHub
3. License: MIT
4. Project website
5. README