Kiuryy/Bookmark_Sidebar: a toggleable bookmark panel for Chromium browsers

A panel beside the page rather than a menu over it

Bookmark Sidebar is a browser extension that adds a toggleable sidebar with all your bookmarks on the left or right side of the screen. The description is plain, and the design follows from it.

The point of the extension is placement: the bookmarks sit beside the page instead of in a manager you have to switch to. The bookmarks are a column of text next to the content, so you can see them and the page at the same time, and you can act on them without leaving the page. That is a small idea, and the extension is essentially that idea done thoroughly.

From the sidebar you can sort, edit, delete and rearrange your bookmarks easily, and the README emphasises that there are many configuration options and that the appearance is fully customizable. For a tool that shows the same list on every page of every site, the appearance and the configuration are not decoration, they are the product.

The author is Philipp Koenig, the project homepage is at extensions.redeviation.com, and the version in the repository's package file is 2.5.7, while the most recent tagged release is 2.5.0 from 2025-08-11. The repository is small, with a `src/` directory, a `build.sh` script, an `eslint.config.mjs` and the licence file.

Chrome and Edge are the supported browsers

The extension is distributed through the Chrome Web Store and the Edge Add-ons store, with download buttons for both in the README, and the browser support statement is more careful than most extensions manage to be.

The extension should work with all Chromium based browsers, while officially only Chrome and Edge are fully supported.

That is a useful distinction to have written down, because Chromium forks change their extension APIs, their store policies and their review processes, and an extension that installs on a fork is not the same as one that is supported on it. A user on Brave or Vivaldi or an embedded Chromium shell may find it works, and if it does not, the project's position is that it was never promised for those browsers.

There is also a build target for Firefox in the tooling, which makes the Chromium only statement a little more complicated than it first appears. The `package.json` scripts include `build:chrome`, `build:firefox` and a `release` script that passes `--target=chrome,firefox` to the build script, so a Firefox artefact can be produced. What the README does not say is that a Firefox build is published or supported, and the store links cover Chrome and Edge only.

The badges in the README are worth a mention for a different reason. The version, the user count and the average rating are all dynamic badges that query the extension's own API endpoint rather than a static value, so the README shows the current published state of the store listing instead of a number that has to be updated by hand.

Forty languages, and a translation contribution path

The extension is available in forty different languages, and the README invites translations directly, asking people who want to help to translate the extension to contribute by submitting some translations.

Forty languages is a lot for a sidebar, and it says something about who uses it. A browser extension that shows text on every page is read constantly, so translation is not a nice to have for the audience, and a project that has collected forty locales has a contributor base that includes people who do not read English.

The support channel is a feedback form on the project site, and the README's note about it is personal in a way that most open source READMEs are not. The author says not to hesitate to contact him by submitting the feedback form, that he is reading all messages and trying to get back as soon as possible.

For a project of this size that level of attention is plausible and is part of why the extension has been maintained across the years of the release history, with tags going back to 2.3.0 in March 2024.

The build is a shell script, Sass and terser

The build system is deliberately small, and reading the `package.json` tells you the whole thing.

"scripts": {
  "init": "npm install && npm install -g npm-check-updates && npm rebuild node-sass",
  "update": "ncu -u --packageFile package.json && npm install",
  "build:chrome": "./build.sh --mode=build --target=chrome",
  "build:firefox": "./build.sh --mode=build --target=firefox",
  "release": "./build.sh --mode=release --target=chrome,firefox"
}

The build is delegated to `build.sh`, which takes a mode and a target, so the same script produces a development build, a release build, and either a Chrome or a Firefox bundle, and the release script asks for both in one call. Everything in the build is a shell script and a handful of npm scripts, with no bundler framework, no transpiler configuration and no test runner in the dependency list.

The five dev dependencies are the interesting part. `eslint` at 9.x with the flat configuration file in the repository root, `sass` for the styles, `html-minifier-terser` and `terser` for shrinking the assets, and `npm-check-updates` for the `update` script, which upgrades the dependency versions in the package file and reinstalls. The `init` script installs the dependencies, installs the update tool globally and rebuilds node-sass, which is the step that would otherwise fail on a fresh machine.

So the extension is written in plain JavaScript and Sass, linted with ESLint, and packaged by a shell script. For a browser extension that reads the browser's bookmark API, that is about the right amount of machinery.

The licence is the thing to read first

The project is licensed under the Microsoft Reference Source License, and the README says so with an unusual final sentence. This project is licensed under the Microsoft Reference Source License, see the licence file for details, and any copyright infringement will be legally pursued.

That last clause is a signal, and it should shape your evaluation.

The MS-RSL is a source-available licence, not one of the OSI approved open source licences, and the repository's own metadata reflects that, listing the licence as a custom one that GitHub cannot classify. The practical difference from an MIT or Apache grant is that you do not have the same set of permissions. Redistribution and modification rights are constrained by the licence's own terms rather than granted broadly, and the enforcement clause makes the consequences of exceeding them explicit.

So there are two different ways to read this project. If you are a user installing it from a store, the licence barely matters, because you are not modifying or redistributing it. If you are a developer who intends to fork it, ship a modified version, or read the code and copy parts of it into something else, the licence is the first thing to read, and the enforcement sentence is a fair signal that the author means business about it.

This is also why the project is a good candidate for the kind of review a store extension deserves, and a poor candidate for the kind of review a dependency deserves.

Where this is the wrong extension

The first wrong case is Firefox as a daily driver. A Firefox build can be produced by the build script, but the store distribution and the support statement are Chrome and Edge, and the native Firefox bookmark model is different enough that an extension written against the Chromium bookmark API is not automatically a Firefox extension.

The second is a user who wants fewer extensions. A panel that shows every bookmark on every page is a permanent piece of screen real estate, and for someone who mostly uses a handful of bookmarks and the browser's own manager, that is a poor trade for an extra extension with access to the browser's bookmark data.

The third is a deployment where an extension from a store cannot be used, such as a locked down managed environment with an approved extension list, or a browser that a team has stripped down. There is no enterprise distribution story in the repository.

The fourth, and the one specific to this project, is redistribution. The MS-RSL and the enforcement clause mean that a fork, a repackaged build or a copy of the source inside another product is a legal question rather than a technical one, and the project is a single maintainer with an explicit statement of intent.

On the state of the repository, the last push was on 2026-09-26 and the repository is not archived, so work continues. The tagged releases are infrequent by software standards, with 2.3.0 on 2024-03-30, 2.4.0 on 2025-03-14 and 2.5.0 on 2025-08-11, while the package file sits at 2.5.7, which suggests the store build moves ahead of the tags. A compact changelog is published on the project site alongside the full release history on GitHub.

Editorial conclusion

Adopt Bookmark Sidebar if you want your bookmarks visible beside the page rather than behind a menu, and you use Chrome or Edge, since those are the two browsers the project says are fully supported. Do not adopt it as a component of a product you ship, because the Microsoft Reference Source License is a source-available licence with an enforcement clause rather than an OSI open source grant, and do not expect a Firefox build you can install today, because the published stores are the Chrome Web Store and the Edge Add-ons store and Firefox is not a supported target. Verify first that your Chromium browser of choice is one the project lists, that the version you install matches the store listing rather than the version in the repository's package file, and that the MS-RSL terms allow what you intend to do with the code.

Frequently asked questions

Official sources

1. Issues
2. Kiuryy/Bookmark_Sidebar on GitHub
3. Project website
4. README
5. Releases