# BewlyCat: a Bilibili homepage overhaul built on BewlyBewly > BewlyCat is a Vue browser extension that restyles the Bilibili homepage and adds playback features BewlyBewly does not ship. It is a personal-use fork with a narrow scope, a hard ban on client packaging, and a licence you have to read yourself. **keleus/BewlyCat** — BewlyCat——基于BewlyBewly开发的Bilibili拓展 - Repository: https://github.com/keleus/BewlyCat - Website: https://chromewebstore.google.com/detail/bewlycat/oopkfefbgecikmfbbapnlpjidoomhjpl - Stars: 4,337 · Forks: 144 - Language: Vue - License: NOASSERTION - Published: 2026-09-23 · Updated: 2026-09-23 · Language: en - Canonical page: https://hysenlabs.com/projects/keleus-bewlycat ## What BewlyCat changes on Bilibili, and who the fork is for BewlyCat is a browser extension that rewrites the Bilibili homepage in place. The README's own framing is modest: "Just make a few small changes to your Bilibili homepage." The project is a fork of BewlyBewly, developed under the MIT licence of the original with permission from that author, including the right to publish on the Chrome Web Store. The maintainer states plainly that the fork is tuned to his personal habits, and that feature requests and bug reports are welcome but not the design driver. That framing matters more than the feature list. This is not a general-purpose enhancement suite with a roadmap negotiated by users. The README lists what was added and what was deleted, and several deletions exist to cut maintenance cost rather than to improve the product. The old top bar was removed and the remaining top bar component was rewritten; animations that interfered with function were dropped; the bundled fonts were removed, taking the package from 14.4M to 600K. The additions cluster around two areas. First, navigation and playback: opening video cards and top bar links in a background tab, forward and back through homepage recommendations, remembering the playback speed you last chose, random playback inside a collection, and keeping the default playback mode for collection videos. Second, filtering and audio: a web-mode recommendation filter that drops videos by like-to-play ratio, and local loudness balancing that levels volume between videos and disables the player's native equaliser through the player component. The README documents the loudness feature separately in docs/local-loudness.md, covering target loudness, strength adjustment and a running status display. Who is this for? A Bilibili user on Chrome, Edge or Firefox who already likes the BewlyBewly look and wants the extra playback behaviour without switching to a userscript manager. The README is explicit that it is not for anyone who wants the plugin wrapped inside another client, and not for Safari users. ## How the extension is put together: Vue, Vite and a split build The repository is a Vue project. The package.json declares "type": "module", pins pnpm@11.17.0 as the package manager, and splits the build into four stages: build:prepare, build:js, build:inject and build:bg. Reading the scripts, the content script is built by vite.config.content.ts, the injected script by vite.config.inject.ts, and the background script by tsup. The web view is built by vite.config.ts. That is the standard shape of the vitesse-webext template, which the README credits as the project's starting point. The split explains a real behaviour: the extension does not run as one monolithic script. A content script, an injected page script and a background worker each get their own bundle and their own lifecycle. It also explains why the project ships three separate browser targets. build sets the production flag and runs the four stages in order; build-firefox repeats the sequence with FIREFOX=true and a Firefox-specific clean step; build-safari does the same with SAFARI=true. The pack script then produces extension.zip, a Firefox zip and a Firefox sources zip. The repository also carries convert-safari, which runs xcrun safari-web-extension-converter against ./extension-safari into ./extension-safari-macos. So a Safari build is technically reachable through the toolchain, but the README states the project will not package Safari and will not do bulk Safari-only adaptation, inviting anyone who needs it to build it themselves. That is a scope decision, not an oversight. The same pattern shows in the Firefox store note: the README says version 1.0.2 fixed the drawer problem there, implying the Firefox path has had its own defects. One architectural detail worth flagging: the repository root contains AGENTS.md and CLAUDE.md alongside the usual config files. Those are instruction files for AI coding assistants, which tells you something about how the maintainer works. It is not evidence of code quality either way, but it is unusual enough to mention when you are deciding whether the project's conventions match yours. ## Installing BewlyCat from a store or from a release zip The README gives two routes: online installation from the Chrome Web Store, Edge Addons or Firefox Addons, and local installation from a CI build or a stable release. Store review timing varies, and the README warns that Chrome usually lags 30 minutes to 15 days, Edge 3 to 30 days, and Firefox 1 to 30 minutes. It also asks users not to chase review status in issues, since the stores control it. For local installation on Chrome or Edge, the README's recommended path is to download extension.zip from the Releases page and drag it onto the extensions page. Open the extensions page first, then drop the file: ```bash # open the extensions page in your browser # Chrome: chrome://extensions # Edge: edge://extensions ``` Drag extension.zip onto that page. The README presents this as the whole procedure. There is a second, more manual method documented in a collapsed section. Download extension.zip, unzip it, then load the unpacked folder. In Chrome: ```bash # 1. go to chrome://extensions/ # 2. turn on Developer mode # 3. click "Load unpacked" # 4. select the unzipped extension folder ``` The Edge steps are identical with edge://extensions/ as the address. The README notes the unpacked folder is the one produced by unzipping, so keep the directory structure intact. If you prefer to build it yourself, the package.json exposes dev and build. A development run clears previous output and starts the watchers in parallel: ```bash pnpm install pnpm dev ``` For a production build of the extension: ```bash pnpm build ``` That runs clear, build:prepare, build:js, build:inject and build:bg in sequence. The README points contributors to docs/CONTRIBUTING-cmn_CN.md for build guidance. Note that the contributing document is in Chinese, as is the README itself. One version constraint comes with the installation. The README states that Bilibili changed its homepage recommendation API in January 2026, and that version 1.5.6 or later is required to match the new homepage recommendations, rankings and categories. Any install below that version will not behave as described. ## Where BewlyCat stops being the right tool The most consequential limitation is written into the project as a rule rather than a caveat. The README states, in an important block, that this plugin and its fork code may not be wrapped into any form of client. The stated purpose is to improve the experience of the official Bilibili site only. If your plan is to embed this extension in a desktop shell, a mobile wrapper or a distribution that repackages it, the project forbids it outright. Safari is the second boundary. The README says the project will not package Safari and will not do large amounts of Safari-only adaptation. The build script for Safari exists, and convert-safari invokes Apple's converter, but that is a toolchain, not a supported artefact. You are on your own for the resulting build. The third limitation is the maintainer's own statement that the fork targets his personal usage. That is a design constraint with practical consequences: features that do not fit his habits are unlikely to be prioritised, and deletions happen for his convenience. The removed Cantonese translation is the clearest example. The README explains it is now maintained by the BewlyBewly author, and that when a translation is missing the extension falls back to English results. If Cantonese translation was the reason you used the upstream project, this fork is a regression. There is also a documentation gap. The README documents the loudness feature by pointing at docs/local-loudness.md, and the repository does contain a docs/ directory, but the README itself does not describe rollback behaviour for settings, nor how to revert to a previous extension version after a store update. The .release-it.json file suggests releases are automated, but the README does not document a downgrade procedure. If you need pinned versions, plan for it before a store pushes an update you did not want. Finally, the licence. The repository's licence identifier is NOASSERTION, while the README says the project is developed under MIT on the basis of the original project. Those two signals do not match, and the README's statement is about the upstream licence, not a clean statement of this fork's terms. Treat the licence question as unresolved until you read LICENSE yourself. ## BewlyCat against BewlyBewly and the userscript route The obvious alternative is BewlyBewly, the project BewlyCat forks. The difference is not a rewrite; it is a delta. BewlyCat keeps the upstream base and adds a specific set: background tab opening for video cards and top bar links, forward and back through homepage recommendations, a user panel entry for claiming membership benefits, collection autoplay-off for listening through a playlist, random collection playback, a remembered playback speed, an external watch-later control on the video detail page, a custom dark-mode base colour, and like-to-play ratio filtering in web mode. It also ports most of the customisable shortcuts from the Extension for Bilibili Player plugin. On the other side of the ledger, BewlyCat removes the built-in fonts (14.4M down to 600K), removes the old top bar and rewrites the remaining one, and removes animations that got in the way. The Cantonese translation moves back to BewlyBewly's author. So the choice is not "better or worse" but "which delta do you want". If you rely on the Cantonese translation or on the bundled fonts, upstream serves you better. If you want the playback and filtering additions, the fork is the one that has them. The other route is a userscript manager with something like Bilibili-Evolved, which the README credits as a source for some feature implementations. The difference in approach is structural. Bilibili-Evolved is a userscript, so it runs in whatever manager you already use and does not need a store review cycle or a browser-specific package. BewlyCat is a packaged extension with three store listings, a background script and an injected script, which gives it more room for cross-page behaviour and a background worker, at the cost of store review latency (the README's own 30 minutes to 15 days for Chrome) and per-browser packaging. Bilibili-Evolved is also a much larger surface. If you want a handful of playback tweaks rather than a broad enhancement platform, the extension's narrower scope is a point in its favour, not against it. ## Maintenance, releases and what the licence question costs you The repository is not archived, and the last push was on 2026-09-23. Releases are frequent: v1.7.8 on 2026-08-24, v1.7.9 on 2026-09-14 and v1.7.10 on 2026-09-15, which matches the version in package.json. The release-it configuration in the repository root is consistent with that cadence. Upgrade cost is therefore mostly the store review delay rather than a long gap between versions; the README states the three stores are submitted together and that actual availability depends on each store's review speed. The maintenance risk is not staleness but direction. A fork tuned to one person's habits can change in ways you did not ask for, and the README's list of deletions is the evidence: fonts, old top bar, animations and the Cantonese translation all went away. If any of those mattered to you, an upgrade can remove them. The README does not describe a rollback path, so if you install from a store you are exposed to whatever the store approves next. On licensing, the README says the project is developed under MIT on the basis of the original project and that the original author authorised this use, including Chrome Web Store publication. The repository metadata, however, reports the licence as NOASSERTION, so the machine-readable licence field does not confirm MIT. The README also imposes a use restriction that is not a licence term in the usual sense: no client packaging of the plugin or the fork code. That restriction is stated by the maintainer in the README, and it is a condition on how the project may be used, separate from the copyright licence. Read LICENSE and the README together before you redistribute anything, and take your own advice on whether the two are consistent. ## Conclusion Adopt BewlyCat if you want a restyled Bilibili homepage plus the fork's extras (background tab opening, collection autoplay-off, remembered playback speed, local loudness balancing) and you accept a maintainer who says the project is tuned to his own habits. Skip it if you need Safari, want a client wrapper, or depend on the Cantonese translation that was removed. Before installing, open the release page and confirm the version is at least 1.5.6, since the README ties the January 2026 homepage recommendation API change to that version. ## FAQ ### How do I install BewlyCat on Chrome or Edge? Install it from the Chrome Web Store or Edge Addons, or download extension.zip from the Releases page and drag the file onto chrome://extensions or edge://extensions. The README also documents an unpacked-folder route using Developer mode and Load unpacked. Store review timing varies, from about 30 minutes to 15 days on Chrome. ### Does BewlyCat work with Safari? No packaged Safari build is provided. The README states the project will not package Safari and will not do large Safari-only adaptation, and invites users to build it themselves. The repository does contain a build-safari script and a convert-safari script that runs Apple's safari-web-extension-converter. ### Which version of BewlyCat do I need after Bilibili's homepage API change? The README states that Bilibili adjusted the homepage recommendation API in January 2026 and that version 1.5.6 or later is required to match the new homepage recommendations, rankings and categories. Installing below that version will not behave as described. ## Sources - [Issues](https://github.com/keleus/BewlyCat/issues) - [keleus/BewlyCat on GitHub](https://github.com/keleus/BewlyCat) - [Project website](https://chromewebstore.google.com/detail/bewlycat/oopkfefbgecikmfbbapnlpjidoomhjpl) - [README](https://github.com/keleus/BewlyCat/blob/main/README.md) - [Releases](https://github.com/keleus/BewlyCat/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/keleus-bewlycat