# azusa-player: a Bilibili audio player that lives in the browser extension

> azusa-player is a Chrome and Edge extension that turns Bilibili videos into an audio player, with song title extraction, lyrics search, playlist browsing and download. Its build tooling is unusual for an extension, using Vite, Vitest, Playwright and a live test configuration, and its licence adds terms on top of MIT that users are expected to accept.

**kenmingwang/azusa-player** — A 3rd party Bilibili audio player / 一个Bilibili第三方音频播放器

- Repository: https://github.com/kenmingwang/azusa-player
- Stars: 619 · Forks: 66
- Language: TypeScript
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/kenmingwang-azusa-player

## The extension exists to strip video down to audio

azusa-player is described in the repository description as a 3rd party Bilibili audio player, and the README is short and informal. The intent is stated plainly: it is essentially a third-party audio player for Bilibili, presented as a browser extension, and the goal is to make video lightweight into audio for the purposes of browsing songs, categorizing playlists and downloading.

The feature list is short enough to summarize. There is a default playlist that ships with the project, linking to a collection of cover versions on Bilibili. It supports single-part and multi-part video search, with an adaptation for the collection feature. It implements song title extraction and lyrics search, with the caveat that if title extraction is inaccurate you have to type the name in manually. And the author is explicit that the project is mainly for personal use, that features he is not interested in probably will not be built, and that issues can be sent by Bilibili private message, while pull requests are still welcome.

The single-part and multi-part point has an explicit strike-through in the README noting that the multi-part feature was cut during QA because Bilibili removed the split-part function, with the note left in place rather than deleted. That is a small but revealing detail about the project: it is a tool built on top of another platform's undocumented-ish behavior, and that behavior can change under it.

The extension is published on the Chrome Web Store and the Microsoft Edge add-ons store, and the repository's top level shows a `docs/` directory with the logo assets and a tutorial image, plus `src/`, `public/`, `tests/` and a `CHANGELOG.md`.

## Offline install means downloading a build, unzipping it and loading the folder

There are three install paths, and the offline one is the one a developer will use.

The first two are the browser stores, the Chrome Web Store and the Microsoft Store, both linked from the README. The third is offline installation: download the latest build file from the GitHub releases, extract it, turn on developer mode in Chrome, and load the extracted folder.

That last step is the standard unpacked-extension path, and it has a consequence worth naming before you rely on it. A store install updates itself, and an unpacked folder does not. You are responsible for replacing the folder when a new release lands, and until you do, the extension you are running is the version you extracted, not the version in the repository.

The release history is active. The listed releases are v2.0.4 on 2026-04-13, v2.0.3 on 2026-04-11 and v2.0.2 on 2026-04-11, so two of the three landed within two days of each other. The repository is not archived, and the last push was on 2026-04-13.

The build itself is not a plain webpack setup despite an old-looking workflow badge. The `package.json` scripts show a Vite-based pipeline with an extension mode, where the same source is built either as an extension or as a plain web app:

```json
  "scripts": {
    "dev": "vite --mode extension",
    "build": "tsc && vite build --mode extension",
    "test:e2e": "playwright test",
    "test:ci": "npm run test:run && npm run test:e2e && npm run build"
  },
```

The `private` flag is set to true in the manifest, so this package is not published to a registry. The main field is `index.js` and the version is 2.0.4, matching the latest release tag.

## A three-tier test setup, including a live config that talks to the real site

The test scripts are the most interesting part of the manifest, and they describe three different kinds of confidence.

Unit and component tests run under Vitest, with `test` for watch mode, `test:run` for a single run with a basic reporter, and `test:reg` for a verbose reporter. There is also `test:live`, which runs with `vitest.live.config.ts` and a verbose reporter, and the repository has both `vitest.config.ts` and `vitest.live.config.ts` as separate files. A separate config file for live tests means the live suite is configured differently from the rest, which is what you would expect of tests that hit a third-party site.

End-to-end tests are Playwright, with `test:e2e` and a `test:e2e:headed` variant, and there is a `playwright.config.ts` at the repository root. The CI script chains the three together: unit tests, then end-to-end tests, then the build.

That is an unusually complete setup for a personal project, and it says something about the maintainer's approach. The dev dependencies back it up, with `@playwright/test`, `@testing-library/jest-dom`, `@testing-library/react`, `@testing-library/user-event` and `@types/chrome`. The last one matters, because it is the type surface for the extension APIs the project calls into the browser.

The gap in this setup is obvious once you look at it. A live test suite that depends on Bilibili's current behavior is a test suite that will start failing when Bilibili changes, and the README's own note about the multi-part feature being cut during QA is evidence that this has already happened once. That is not a reason to distrust the project, but it is a reason to expect a live test to fail and to read the failure before assuming the code is broken.

## React and MUI on top of a player library and a lyrics library

The technology stack section names the pieces. It is a Chrome Extension plus React plus MUI, with react-music-player for the player interface, react-lrc for lyrics, and react-chrome-extension-MV3 for the Manifest V3 plumbing. The README also says it referenced the interaction model of the Listen1 Chrome extension player.

The manifest confirms that with a dependency list that includes `react-jinke-music-player` at 4.24.2 and `react-lrc` at 3.2.1, alongside React and React DOM at 18.2.0 and the MUI family at 5.14.9 including `@mui/x-data-grid`. The Emotion packages are there for styling, `@fontsource/roboto` supplies the font, and `@fortawesome/fontawesome-free` provides icons.

Two dependencies deserve a note. `downloadjs` and `file-saver` are there for the download capability, so the save path is a client-side file write rather than a server round trip. And `cross-fetch` is in the list, which is the usual way to make requests from a background script or a content script where the page's own fetch is not available.

The build tooling completes the picture. `@crxjs/vite-plugin` at a 2.0.0-beta.19 is present, and it is the plugin that turns a Vite build into a Chrome extension bundle, which is what makes the `vite --mode extension` scripts work. A Vite config, a Prettier config, an ESLint config, a TypeScript config and a `.editorconfig` sit at the top level, along with `src/`, `public/`, `tests/` and `docs/`.

On the licensing of the code itself, the manifest declares MIT and the README points at the MIT License file. What the licence adds on top is the interesting part, and it is described in the project protocol section as a supplement to MIT that takes precedence in case of conflict. Six numbered clauses follow, and the substantive ones are worth knowing before you install it.

## The supplementary licence asks users to clear cached content within 24 hours

The project protocol section is unusual for a personal extension, and the terms are specific rather than generic.

The first clause states that the project's data comes from the public servers of the official music platforms, that the data is simply filtered and merged before display, and that the project is therefore not responsible for its accuracy. The second clause states that using the project may produce copyrighted data, that the project does not own the ownership of that data, and that to avoid infringement the user must clear the copyrighted data produced during use within 24 hours.

The third clause is about naming, stating that the aliases used for the official music platforms inside the project are just a term for them, carry no malice, and can be changed or removed on request. The fourth covers third-party assets such as fonts and images, which come from the internet and can be removed on request if there is infringement.

The fifth and sixth are liability clauses. The fifth puts responsibility on the user for any kind of direct, indirect, special, incidental or consequential damage arising from use, including lost goodwill, downtime, computer malfunction, and all other commercial losses. The sixth states that the project is completely free and open sourced on GitHub for the world to use for learning and technical exchange, makes no guarantee that the technology inside it does not violate local laws, prohibits use that violates local law, and puts the burden of any illegal use on the user.

The README closes with a line asking that copyright be respected and that legitimate purchases be supported, along with a contact email and the author's Bilibili space.

None of this is legal advice, and the practical reading is narrow. If you use the extension to stream music from a platform as a platform intends, the terms are not doing much work. If you cache a lot of audio locally, the 24-hour clearing obligation is the part that could conflict with how you actually use it.

## Conclusion

Adopt azusa-player if you want a lightweight way to browse Bilibili as audio and you accept that it is a personal-use tool with a licence that asks you to delete cached content within 24 hours. Do not adopt it as a foundation for a product that redistributes music, and do not expect a maintained data pipeline, since the project states it pulls from public servers and disclaims responsibility for data accuracy. Verify first which build you install, since the Chrome Store, Microsoft Store and the offline unpacked folder are three different distribution paths with different update behavior.

## FAQ

### What is azusa-player and how does it work?

It is a Chrome and Edge extension that plays Bilibili videos as audio, with song title extraction, lyrics search, playlist browsing and download. It is built on the Chrome Extension platform with React and MUI, using react-music-player for the player, react-lrc for lyrics and react-chrome-extension-MV3 for the Manifest V3 plumbing.

### How do I install azusa-player?

You can install it from the Chrome Web Store or the Microsoft Store, or offline by downloading the latest build file from the GitHub releases, extracting it, enabling developer mode in Chrome and loading the extracted folder. The offline path does not update itself, so you replace the folder yourself when a new release appears.

### What tests does the azusa-player repository run?

The manifest defines Vitest for unit and component tests, a separate `vitest.live.config.ts` for live tests, and Playwright for end-to-end tests. The CI script chains them as `npm run test:run && npm run test:e2e && npm run build`, and the build itself is `tsc && vite build --mode extension`.

### What licence does azusa-player use?

The manifest declares MIT, and the README states the project is released under the MIT License with the additional protocol taking precedence in case of conflict. The supplementary terms include a 24-hour obligation to clear copyrighted data produced during use, a disclaimer of responsibility for data accuracy, and liability for damage placed on the user.

### Can I build azusa-player from source?

The manifest defines `dev` as `vite --mode extension` and `build` as `tsc && vite build --mode extension`, using the `@crxjs/vite-plugin` to produce the extension bundle. The package is marked private, so it is not published to a registry, and the repository includes a `src/` directory, a `public/` directory and a `tests/` directory.

## Sources

- [Issues](https://github.com/kenmingwang/azusa-player/issues)
- [kenmingwang/azusa-player on GitHub](https://github.com/kenmingwang/azusa-player)
- [License: MIT](https://github.com/kenmingwang/azusa-player/blob/master/LICENSE)
- [README](https://github.com/kenmingwang/azusa-player/blob/master/README.md)
- [Releases](https://github.com/kenmingwang/azusa-player/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/kenmingwang-azusa-player