Webamp: Winamp 2 in the browser, with full skin support

What Webamp actually reimplements, and for whom

Webamp is a reimplementation of Winamp in HTML5 and JavaScript with full skin support. That sentence carries more weight than it first appears. The project is not a generic web audio player wearing a retro theme; the README describes a port of Winamp 2 behaviour, and the topics list confirms the intent: html5, javascript, port, reimplementation, webaudio-api, winamp. The audience follows from that. You are the target user if you want a Winamp-shaped player running inside a page, driven by Winamp skin files rather than by a design system you have to build. The README's In the Wild list shows the pattern in practice: the Internet Archive previews Winamp skins and plays audio tracks with it, Winampify.io is an online Spotify client built on it, and 98.js.org and winxp.now.sh use it inside desktop-clone projects. Those are all cases where the visual and behavioural fidelity of Winamp 2 is the point, not a side effect. If you only need to play an MP3 on a page, Webamp is a large dependency for a small job. The README also states plainly that it works in modern versions of Edge, Firefox, Safari and Chrome, and that IE is not supported, with a caniuse link for the Web Audio API. That is the support boundary, and it is a hard one: no Web Audio API, no Webamp.

The monorepo layout and what each package does

The repository is a monorepo, and the README enumerates what lives inside it. packages/webamp is the NPM module itself. packages/webamp-demo is the demo site served at webamp.org. packages/webamp-docs is the documentation site at docs.webamp.org. packages/ani-cursor renders animated .ani cursors as CSS animations, and packages/winamp-eqf parses and constructs Winamp equalizer preset files (.eqf). packages/skin-database is the server component behind skins.webamp.org, and the README notes it also runs a Twitter bot and a Discord bot. packages/webamp-modern is described as a prototype exploring rendering modern Winamp skins in the browser, which is a useful signal: modern skin rendering is exploratory, not a shipped guarantee, and the package.json deploy script confirms the status by moving its build output into the demo's dist/modern directory rather than publishing it as a library. The examples directory holds runnable starting points: lazy, minimal, minimalMilkdrop, minimalWindowLayout, multipleMilkdropPresets, multipleSkins and multipleTracks. Those names map closely to the questions people actually ask about Webamp, so the examples are worth reading before the API docs. Two of the dependencies are worth noting because they shape behaviour. The README credits Butterchurn, a Milkdrop 2 WebGL implementation, as built and integrated by jberg, which is where visualizer support comes from. The root package.json pins a patched dependency, [email protected], through patches/[email protected]. A beta dependency held in place by a patch file is a maintenance fact you should know before you build on the visualizer.

Installing the monorepo and running the minimal example

The README points to the Webamp Documentation site for instructions on adding Webamp to your site and customizing it. What the README itself gives is the development quick start for the repository, and that is the path to follow if you want to run the examples locally. The root package.json pins the package manager and the Node floor: [email protected] and node >=22.0.0. Start by installing dependencies:

pnpm install

Then build every package. The README notes that Turborepo handles the dependency graph automatically, so ani-cursor and winamp-eqf are built before webamp, which depends on both for workspace linking:

npx turbo build

Library bundles for NPM publishing are a separate task, and the README says it only applies to webamp:

npx turbo build-library

To work on a single package and its dependencies, the README gives a filtered dev command:

npx turbo dev --filter="webamp"

Tests run through Jest, and the root scripts wrap them in Turbo. The README lists a combined lint and type-check invocation:

npx turbo lint type-check

The root package.json also exposes test:integration and test:all, which run the integration-tests task across the monorepo; the README does not describe what those integration tests cover, so treat them as a black box until you read the package-level configuration. If your goal is only to embed Webamp in a page, the README's direction is to go to docs.webamp.org rather than to build this repository, and the examples/minimal directory is the smallest thing to copy from.

Where Webamp is the wrong tool

The licence section is the first real constraint, and it is unusual enough to quote in part. The README says that while the Winamp name, interface, and sample audio file are surely property of Nullsoft, the code within the project is released under the MIT License. So the permissive licence covers the code, not the identity or the bundled audio. If your product needs a clean-room visual identity, or if you plan to redistribute the sample audio, this split matters and the README does not resolve it. Second, the browser support statement is a floor, not a ceiling. IE is explicitly not supported because the Web Audio API is not there. Older embedded browsers and locked-down environments inherit that limitation. Third, the project's own framing puts it in a specific niche. Webamp exists because Winamp 2 looked and behaved a certain way, and the skin system is the feature. If you want a modern audio player with playlists, streaming, gapless playback and a responsive layout, you are fighting the design rather than using it. Mobile is the clearest case: the README does not document a mobile layout, and the interface being reimplemented is a fixed-size desktop window set. Fourth, the modern skin path is labelled a prototype in the README, so planning a product around webamp-modern is planning around unfinished work. Finally, the repository gives no rollback guidance. The README documents build, test, lint and deploy tasks, but nothing about reverting a deployment or pinning a previous release, and the version field in the root package.json is a prerelease string, 0.0.0-next-87012d8d. If your release process requires documented rollback, you will be writing that yourself.

Webamp against a plain HTML5 audio player

The obvious alternative is the browser's own audio element, or a thin wrapper around it. The difference is not quality; it is what each one is responsible for. A plain audio element gives you playback and leaves the interface, the skinning, the equalizer presets and the visualizer to you. Webamp inverts that. It brings a Winamp 2 interface, a skin loader, .eqf preset parsing through winamp-eqf, animated .ani cursors through ani-cursor, and Milkdrop-style visualizers through the Butterchurn integration the README credits. You give up control of the look and take on a much larger dependency, plus a build that expects Node 22 and pnpm 9.12.0 if you work inside the monorepo. There is a second alternative worth naming because the README names it: Winamp Community Update Pack, described there as new plug-ins adding features to Winamp and replacement plug-ins providing better implementations of some plug-ins natively included with Winamp. That is the opposite approach entirely. WACUP extends the original desktop application; Webamp rebuilds the player in JavaScript and runs it in a browser tab. If your users want a real local music library with native file access, WACUP's direction fits better. If you need the player inside a web page, next to other web content, Webamp is the one that fits.

Licence and the cost of keeping up

The code is MIT. The README states that directly and links LICENSE.txt. It also states, in the same paragraph, that the Winamp name, interface and sample audio file are surely property of Nullsoft. Read those two sentences together before shipping anything: the MIT grant covers the repository's code, and the README does not claim to grant rights over the name, the interface or the audio. This is not legal advice, and the README offers none; if your use touches the name or the audio, that is a question for someone qualified to answer it. On maintenance, the last push to the default branch was on 2026-08-28, and the repository is not archived. Upgrade cost is dominated by the toolchain rather than the library. The root package.json requires Node 22 or newer, pins pnpm 9.12.0 through packageManager, and overrides graphql to 16.8.1. The visualizer depends on a patched beta, [email protected], held by patches/[email protected]; when that patch stops applying, you are the one resolving it. The monorepo also carries puppeteer and jest-environment-jsdom as dev dependencies, so CI weight is not trivial. None of this is unusual for a Turborepo project, but it does mean adopting Webamp as a library is cheap while contributing to or forking the monorepo is not.

Editorial conclusion

Adopt Webamp if you want a Winamp 2 player embedded in a web page and you can accept the Winamp name, interface and sample audio being Nullsoft property while the code itself is MIT. Do not adopt it if you need a maintained general-purpose audio player, a mobile UI, or a documented rollback path; the README does not describe one. Verify first that your build runs on Node 22 or newer, that pnpm 9.12.0 matches your tooling, and that the skin you plan to ship is one you have the right to redistribute.

Frequently asked questions

Official sources

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