WebScrapBook: a browser extension that archives pages for later annotation

Capturing pages for retrieval, organization, annotation, editing

WebScrapBook is a browser extension whose stated purpose is to capture the web page faithfully with various archive formats and customizable configurations, for future retrieval, organization, annotation and editing. That list of four verbs is the product definition.

The difference from a bookmark is the word faithfully. A bookmark stores a URL and hopes the page is still there. An archive format stores a copy of the page, and the extension's own topic list includes both archive and maff, which points at MAFF, an archive format. The point of storing a copy rather than a link is that a page captured today can be read, searched and annotated in five years, which is a problem that link rot makes urgent for research work.

Organization and annotation are where the extension goes beyond a capture tool, and editing is the furthest step of all, since an archived page that can be edited becomes a working document rather than a record. The project also inherits from a legacy Firefox add-on, ScrapBook X, which is a useful piece of context: this is the second generation of a tool with a long history, not a new experiment.

The primary language is JavaScript, the package is marked as an ES module, and the version in package.json is 2.27.3.

One extension, six build targets, two manifest generations

The build configuration is where the compatibility story lives, and it is unusually thorough. The build script is a single Node entry point, tools/build.js, called with a target and a mode:

npm run dev:chromium
npm run dev:firefox
npm run pack:chromium
npm run pack:firefox

Underneath those four convenience scripts sit six targets. There is chromium, chromium-mv2 and chromium-mv3, and firefox, firefox-mv2 and firefox-mv3. The mv2 and mv3 suffixes are the manifest generations, and shipping both means the extension can be installed on a browser that has not yet moved off Manifest V2 as well as one that requires V3.

That double support is the single most consequential engineering decision in the project, and it cuts both ways. A Manifest V2 build can use APIs that V3 restricts, and a Manifest V3 build runs under a service worker model with different extension lifetime rules. Maintaining two manifests for two browser families means four combinations in practice, and it means every change to the extension has to be checked against all of them.

The pack mode produces distributable builds, and the presence of web-ext in the dev dependencies points at Mozilla's extension tooling being used for the Firefox side. The dev mode builds and loads for development, which is what you want in a hot reload loop.

The build script does the targeting, and the developer does not hand-edit manifests, which keeps the six variants consistent with each other.

The browser matrix is wider than Chrome and Firefox

The extension is published through the usual store channels, with badges for GitHub tags, the Firefox add-on site, the Chrome Web Store and the Microsoft Edge add-ons page. The list of known supported browsers is wider than those four.

For Chromium-based browsers the project names Google Chrome, Microsoft Edge, Chromium itself, Opera, Vivaldi and Brave, and for mobile it names Kiwi. For Firefox-based browsers it names Firefox, Waterfox and Tor Browser, and for mobile it names Firefox for Android.

Two entries in that list carry more weight than the others. Tor Browser and Waterfox are not mainstream targets, and a project that lists them is signalling that the extension works in configurations where the browser is hardened, the user agent is unusual, and the extension APIs behave differently. That is a reasonable signal for a tool whose purpose is capturing and storing the pages you visit, since those users are exactly the ones for whom local archival matters most.

Kiwi for Android and Firefox for Android mean the extension is not desktop-only, which matters for a capture workflow, because a substantial share of the pages worth archiving are read on a phone.

The extension identifiers are visible in the store links, and the Firefox listing and the Chrome Web Store listing use different identifiers, as is normal when a project ships separate builds per store.

Testing is Mocha over mjs test files, linting is ESLint

The development setup is plain and modern. Linting runs eslint with a flat config, eslint.config.js, and the dev dependencies show the usual pieces: the eslint compat package, the stylistic plugin, eslint-plugin-import, and globals for the environment definitions. Formatting is not enforced by a separate tool in the dependency list, which suggests Prettier is either not used or is handled outside the npm scripts.

Testing uses Mocha, with the spec pattern configured in the package.json as src/test/test_*.mjs. The test files sit next to the source in src/ rather than in a separate top-level test directory, and the .mjs extension matches the ES module type declared for the package. The whole suite is a single mocha invocation, so it runs in Node rather than in a browser harness, which means the tests cover the parts of the extension that are pure logic: parsing, configuration, archive generation, and the tools that do not require a live browser.

Rollup is the bundler, and glob appears in the dev dependencies, which is consistent with a build step that collects sources across the src/ tree.

The test story is modest. A browser extension that manipulates pages has a large surface area that only a browser can exercise, and a Node-only Mocha suite does not reach it. That is not a criticism so much as a boundary to know about before you rely on the test suite as a safety net when changing capture behaviour.

What the repository holds, and where the documentation actually lives

The top level of the repository is short: src/ for the extension source, tools/ for the build script, doc/ for assets including the screenshot used in the README, an eslint.config.js, a package.json, and three documents that matter.

CHANGELOG.md is the release history, and DEVELOPMENT.md covers working on the code. LICENSE.txt holds the licence.

The critical point for anyone evaluating this project is that the user-facing documentation is not in the repository. The README states that for the installation and usage guide, frequently asked questions and further details, you should visit the documentation wiki, and points at the wiki's Intro page. The wiki lives in the repository's own wiki area, so it is versioned separately from the code and can be edited without a pull request.

That has a consequence. A feature described on the wiki may not be in the version you have installed, and the wiki is not tied to a tag. The practical habit is to check the CHANGELOG for the version you are running before reading the wiki, so you know whether a documented behaviour applies to you.

The absence of GitHub releases compounds this slightly. The badge links to the tags rather than to a releases page, and the changelog is the record. There is no published release schedule, so a user who wants to know whether an update is likely cannot tell from the repository.

Maintenance state, the licence, and what a user inherits

The repository is not archived, and the last push was on 2026-09-28, so the code is being worked on. The version in package.json is 2.27.3, and the project publishes to three different stores, which means a release is a multi-step operation across two manifest generations and two browser families.

The licence is MPL-2.0, and the badge in the README links to the licence file in the repository. MPL-2.0 is a file-level copyleft licence: if you modify a covered file and distribute it, that file's source must be made available under the same terms, while files you link against are unaffected. For an extension that most people install rather than modify, that means nothing changes. For a team that wants to fork the capture logic and ship a branded build, it means the modified files have to come back out as source.

There is also a practical difference between a browser extension and a library here. An installed extension carries the code of its dependencies inside the browser, so a team using WebScrapBook to build an internal archive pipeline is running that code inside the browser, on machines it partly controls, and needs a plan for updating the extension across the fleet. The store update cycle is the upgrade path there, not npm.

The absence of tagged releases, the wiki living outside the version history, and the multi-store release process together mean the project is maintained by someone who controls the release pipeline end to end. That is a factor to weigh when you decide how central this tool should be in a long-lived archive workflow.

Editorial conclusion

WebScrapBook fits a researcher, archivist or heavy reader who wants pages captured in a form they can search and annotate later rather than as a pile of loose bookmarks, and the multi-browser support and the MAFF archive format make it a real archiving tool rather than a screenshot button; it is the wrong choice if you want a lightweight bookmark manager or if your workflow depends on a proprietary note format you cannot migrate, and before you commit you should read the wiki intro page, because the configuration surface and the archive format options are documented there rather than in the repository, and the repository itself ships a CHANGELOG instead of tagged releases.

Frequently asked questions

Official sources

1. danny0838/webscrapbook on GitHub
2. Issues
3. License: MPL-2.0
4. README