BilibiliSponsorBlock: a SponsorBlock port that skips sponsored segments on Bilibili

The problem: sponsor reads inside Bilibili videos

A sponsored segment in a Bilibili video looks like the rest of the video. There is no marker, no chapter, no separate stream. Viewers either scrub past it by guesswork or sit through it. SponsorBlock solved this for YouTube by collecting segment timestamps from viewers and shipping them to an extension that seeks past each one. BilibiliSponsorBlock applies that model to Bilibili, and the README frames it plainly: the extension fetches segment data and skips the marked ranges so playback continues without the ad.

The target user is someone who already watches Bilibili in a desktop browser and is willing to install an extension. The README also lists segment categories beyond sponsorship: opening and ending animations, the prompt to like, coin and favorite, and a jump to the video cover position. That last one is a Bilibili-specific idea; on YouTube the equivalent behavior is not a standard category. The project is maintained by one person in their spare time, which the README states directly, and it points to a donation page.

How the extension decides where to jump

The mechanism mirrors SponsorBlock. Viewers submit time ranges for a video, the server stores them, and the extension requests the ranges for the video currently playing and seeks past them. The README says all segment data is crowd-submitted and that you can submit your own. It also publishes the full segment database as a zip at download.bsbsb.top/database.zip, which is unusual for an extension of this kind and makes the data usable outside the extension itself.

The client is a TypeScript web extension built with webpack, with React and antd in the dependency list, so the options and popup surfaces are React components. The manifest directory and the webpack directory hold the build inputs; the package.json scripts drive web-ext for local runs. The port keeps most of the original UI and interaction model, per the README, and the API is close enough to the original that the README tells developers to consult the SponsorBlock API wiki first and the project's own wiki for the differences.

One port-specific feature is worth calling out. The README says the extension can bind a re-uploaded video so that its segments are pulled from the SponsorBlock database. That is a real answer to a Bilibili problem: the same content is often re-posted under a new BV id, and without binding, the segment data would have to be re-collected from scratch.

Installing BilibiliSponsorBlock and skipping your first segment

The README gives two install paths. The extension is listed on the Chrome Web Store and on the Mozilla add-ons site, and Chromium browsers need kernel version 102 or newer. If you cannot reach those stores, download the unpacked build from the latest GitHub Release: `ChromiumExtension.zip` for Chrome, Edge, 360 and other Chromium-based browsers, `FirefoxExtension.zip` for Firefox. Unzip it, open the browser's extension management page, enable developer mode, click load unpacked, and select the extracted folder.

To confirm it works, the README names a test video, BV14741127BN, and an example video, BV1bY4y1v7Mb. Open either on bilibili.com with the extension enabled and watch whether playback jumps past a marked range.

Building from source follows the usual Node flow. The repository ships `config.json.example`, and the Safari instructions show the copy step and the dependency install:

cp config.json.example config.json
npm ci

The Safari build is the one path that needs a toolchain beyond Node. The project provides a script that produces an Xcode project in `safari/` at the repository root:

npm run build:safari:macos

After that you open the generated `safari/` project in Xcode, build and run it, then enable the extension under Safari settings. The script accepts environment variables if you want different project metadata:

BSB_SAFARI_APP_NAME="小电视空降助手" \
BSB_SAFARI_BUNDLE_ID="top.bsbsb.safari" \
BSB_SAFARI_PROJECT_DIR="safari" \
npm run build:safari:macos

Contributor setup is documented in CONTRIBUTING.md rather than the README, so expect to read that file before sending a patch.

What the port gave up, and when it is the wrong tool

The README lists the differences from SponsorBlock as deliberate removals. Multilingual support is gone; the extension ships Simplified and Traditional Chinese only. Mobile H5 support is gone. Third-party mirror site support is gone, though the README invites discussion if a mirror site has enough users. Each of these is a boundary you can hit.

If you watch Bilibili on a phone browser, this extension does not help you, and the README says so rather than leaving it ambiguous. If you read the interface in English, the options pages will be Chinese. If you rely on a mirror front end, segment lookups will not resolve there. And because the whole thing depends on crowd-submitted timestamps, a video nobody has annotated is skipped nowhere; the extension has nothing to act on until someone submits a range. That is the same cold-start property SponsorBlock has, and it is the honest reason a given video may play untouched.

The project also states it is maintained by one person in their spare time. Releases in the recent history are frequent (0.14.1, 0.14.0, 0.13.1 within about a month), and the last push to the default branch was on 2026-09-22, but a single maintainer is a real continuity risk for anything you depend on daily.

BilibiliSponsorBlock versus SponsorBlock and Bilibili Evolved

SponsorBlock is the upstream project and the obvious alternative, but it targets YouTube. Its segment database is built around YouTube video ids, so it does not resolve Bilibili BV ids on its own. BilibiliSponsorBlock exists precisely because that gap is not bridgeable by configuration: the ids, the site behavior and the segment categories differ. The binding feature for re-uploaded videos is the one place the two databases touch, and it is a port-specific addition rather than something SponsorBlock offers.

Bilibili Evolved is a different kind of tool. It is a userscript that modifies the Bilibili interface itself, adding interface changes and playback options, rather than being a segment-skipping extension with a submission backend. If your goal is a different Bilibili layout, Evolved is the closer fit. If your goal is to not watch sponsor reads, the crowd-sourced timestamp model here is the direct answer, and Evolved does not provide that database.

On the extension side, the practical difference between this project and SponsorBlock is scope, not architecture: same idea, same API shape, narrower platform support and a Chinese-only UI.

Licence, maintenance and upgrade cost

The project is under GNU GPL v3, and the repository carries a separate LICENSE-APPSTORE.txt alongside it, which suggests the Safari packaging path needed a licence carve-out. GPL-3.0 matters if you plan to fork or redistribute: derivative distribution carries source obligations, and the Safari build adds its own file to read. This is a description of what the repository contains, not legal advice.

Upgrade cost is low for users. Chrome and Firefox installs update through their store listings, and the README notes that Chrome, Firefox and Edge store submissions can be pushed in one go through GitHub Actions once store API credentials are configured, with details in docs/publishing.md. Self-built installs are the exception: an unpacked extension loaded from a zip does not auto-update, so you re-download the release zip and reload it. The Safari path is heavier, since it goes through Xcode and you rebuild after each source change. For developers, the dependency list is small (React, antd, a content-script polyfill) and the toolchain is webpack plus TypeScript 5.9.2, so a fresh contributor is not facing a deep or unusual build.

Editorial conclusion

Adopt it if you watch Bilibili in a Chromium browser or Firefox and want sponsor reads skipped without manual seeking; the store listings and the unpacked release zips cover both cases. Do not adopt it if you need mobile H5 support, third-party mirror sites, or multilingual UI, all of which the README says were dropped from the original port. Before relying on it, open the test video BV14741127BN and confirm a segment is skipped, then check the config.json.example keys your build needs.

Frequently asked questions

Official sources

1. hanydd/BilibiliSponsorBlock on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases