# Scratch Addons: one browser extension that carries a whole addon ecosystem > Scratch Addons packages community features for the Scratch website and project editor into a single configurable browser extension, where each addon is a manifest plus a userscript or userstyle. It is also usable outside the extension, since editors such as TurboWarp and Adacraft can load most editor addons directly. **ScratchAddons/ScratchAddons** — All-in-one browser extension for Scratch. - Repository: https://github.com/ScratchAddons/ScratchAddons - Website: https://scratchaddons.com - Stars: 817 · Forks: 437 - Language: JavaScript - License: GPL-3.0 - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/scratchaddons-scratchaddons ## One extension carrying many small community features Scratch, the visual programming site from MIT, has a large community that writes small features for it: extra editor buttons, theme changes, tweaks to the project page, sprite utilities. Historically those features tend to arrive as separate one-off extensions, each with its own permissions, its own update cycle and its own place in the browser's extension list. Scratch Addons takes the opposite approach. Its stated mission is to provide a centralized, up-to-date platform for community development of new features and themes for Scratch, and the extension description calls it an all-in-one browser extension for Scratch. The extension provides a settings page where users can enable, disable and configure addons, interprets addon manifests, stores user settings and provides APIs to userscripts. A new version of the extension is released to the stores regularly with new addons and features. The audience splits in two. One group is Scratch users who want a curated set of features they can toggle from a single place rather than installing a dozen extensions. The other is addon developers, who get a documented structure, a manifest format, a shared API layer and a distribution channel without having to write an extension from scratch. The design also assumes coexistence. Addons are designed to be compatible with each other, and they are developed with performance, internationalization, accessibility and privacy in mind. That last point is what drives the main world execution model described below, and it is also where most of the security trade-offs live. ## An addon is an addon.json manifest plus userscripts or userstyles The unit of the ecosystem is the addon. According to the documentation, an addon mainly consists of one or more userscripts written in JavaScript, or userstyles written in CSS, that run on the Scratch website or in the project editor. Each addon declares its own manifest, an addon.json file. That file specifies under which circumstances each userscript and userstyle should be injected into the page, and it also carries user-facing information such as the description of the feature and information about the addon's settings. The injection conditions are the interesting part of the design: a script does not simply run on every Scratch URL, it runs when the manifest says it should, which is how the same extension can ship both project page tools and editor tools without either interfering with the other. Userstyles are the CSS half of the model and follow the same manifest rules. Themes and visual tweaks are expressed that way, with no JavaScript involved. Because the manifest declares settings, and the extension provides the settings page, an addon does not have to build its own configuration UI. It declares settings and the extension renders them. That is a large part of why dozens of addons can sit behind one consistent interface. ## Userscripts run in the main world, not the extension world This is the single most consequential technical decision in the project. Userscripts work similarly to extension content scripts running in the main world, described as the unprivileged context where chrome.* extension APIs are not available. The practical consequences cut both ways. In exchange, a userscript can reach the Scratch page's own JavaScript objects directly, including a reference to the Scratch VM, which is the runtime that executes user projects. Anything that needs to observe or influence the editor has to work at that level, because that is where the editor's state lives. The cost is that the whole chrome.* family of extension APIs is off limits. There is no extension messaging to a background page, no privileged storage, no browser-level tabs or downloads control from inside a userscript. Any addon that needs those things has to be structured differently, or not be a userscript at all. On top of the browser context, userscripts get their own API surface. The addon.* APIs are built-in utilities for common tasks: waiting until a certain element exists on the page, listening for settings change events, getting a reference to the Scratch VM object, and similar. The waiting utility in particular removes a lot of duplicated code, since page elements in a single page application appear and disappear as the user moves around the editor. The settings change event matters for a subtler reason. Because addons can be enabled, disabled and reconfigured at runtime, a userscript that reads a setting once at startup will hold a stale value. Listening for changes is how a well behaved addon reacts to the user changing a setting mid-session. ## How the repository is laid out The file structure tells you where responsibility sits. Under the Addons heading, addons-l10n holds the translation files for addon strings, one file per addon. addon-api is the implementation of the addon.* JavaScript APIs. The addons directory gives each addon its own directory, which must include a manifest file named addon.json. The libraries directory holds third-party libraries and other utilities, some of which are used by addons. The rest of the top level covers the extension itself rather than the addons. There are directories for background scripts, content-scripts, popups and webpages, plus a manifest.json at the root, an _locales directory for the extension's own interface strings, and an images directory. The default branch is master. Editor configuration is checked in as well: an eslint.config.mjs, a .prettierrc.json with a .prettierignore, and an .editorconfig. The .github directory holds GitHub templates and workflows, which is where the release automation and review process for incoming addons live. The split between addon-api and the individual addon directories is the boundary a contributor has to understand. Code that any addon can use belongs in addon-api and becomes available through the addon.* namespace; code specific to one feature stays in that feature's directory and is loaded through its manifest. ## Getting Scratch Addons installed and configuring it The front page points to two distribution channels, the Chrome Web Store and Firefox Add-ons, and the project also runs its own site at scratchaddons.com where the addon documentation lives. The repository does not document a command line install path, so installation is done through the browser stores rather than from a built artifact you assemble yourself. Once installed, the extension adds a settings page to the browser's extension list. That page is the control surface for everything: individual addons can be enabled, disabled and configured there, and the settings the extension stores are what the addon.* APIs expose to the running userscripts. The addon documentation is published under the site, including pages on getting started with addon basics, the userscript and userstyle formats, the addon manifest reference, and a general development section. Those pages are where an addon author goes first, because they describe the manifest fields and the available utilities rather than repeating what the repository already shows. For an addon author, the practical loop starts in the addons directory, where each new addon needs its own folder with an addon.json file. That manifest declares when the scripts should be injected, what the user-facing description says and which settings exist. The scripts themselves then rely on the addon.* utilities for element waiting, settings change events and access to the Scratch VM reference. ## Addons that run without any browser extension at all The most interesting fact about the ecosystem is that it is not tied to the extension. The documentation notes that other open-source projects, such as Scratch forks, can make use of the addons as well. Two examples are named. TurboWarp and Adacraft, both Scratch editor forks with their own project editor implementations, allow you to use most of the editor addons without installing browser extensions, and in the case of TurboWarp Desktop, even while offline. The TurboWarp Desktop link points at a desktop build of that editor. This is a meaningfully different approach from the extension. An addon that runs inside a fork's editor is part of the editor build, so it ships and updates with the fork and needs no browser permissions at all. The cost is that it can only work where the fork's editor supports it, which is why the documentation says most editor addons rather than all of them, and why editor-focused addons are the ones that travel. Addons that depend on the Scratch website itself, rather than the editor, are the ones that need the extension. So there are two adoption paths with different properties. The extension gives you the full addon set on the live Scratch site, updated through the stores. A fork gives you the editor addons only, with no browser extension installed and no dependency on the live site. ## Where Scratch Addons does not fit The main world execution model is the hard boundary. Since chrome.* extension APIs are unavailable to userscripts, an addon that needs extension privileges cannot be implemented as a userscript. Addons built on top of the addon.* utilities and the Scratch VM reference work; addons that need to talk to a background page or read privileged browser state do not fit that shape. A second boundary is that everything runs inside the page. A userscript shares the page's privileges and the page's origin, which is exactly why the extension is careful about permissions, privacy and compatibility between addons. The upside is that addons can see and change what the editor does, an ability no separate extension has. The downside is that you are trusting a large set of community scripts with access to your Scratch session, which is a decision users make one addon at a time on the settings page. A third practical limit is distribution. Addons reach users through the store release of the extension, so publishing a new addon means it ships inside a versioned extension release. The listed releases show that pattern, with v1.45.0, v1.45.1 and v1.45.2 in April 2026. The fork route has the same property in reverse, since addons there ship with the fork's own releases. For a developer who wants to modify Scratch behaviour for their own use only, these constraints are irrelevant and the addon APIs are more than enough. For someone building a production tool around Scratch, the main world model and the store distribution are both limits worth planning around. ## Licence, maintenance and the cost of adopting the pattern The project is published under the GPL-3.0 licence, with the LICENSE file at the repository root. For anyone thinking about reusing the addon format or the API layer in a product of their own, that is the constraint to read first, because GPL terms attach to derivative works rather than to ideas. This is not legal advice, and the practical question is whether a distributed product that incorporates this code needs to follow GPL obligations, which is a question for your own counsel. The repository is not archived, and the last push was on 2026-10-18. Recent releases are v1.45.2 on 2026-04-29, v1.45.1 on 2026-04-25 and v1.45.0 on 2026-04-05, which is consistent with the documentation's statement that a new version of the extension is released to the stores regularly with new addons and features. The upgrade cost sits in the addon manifest and the API surface rather than in a dependency version. An addon written against one version of the addon.* utilities can break when the API changes, and addons live inside the extension release cycle rather than in their own independent update channel. Authors who want their addon to follow the extension need to track the release notes in the .github directory. Internationalisation is handled per addon, with one translation file per addon in the addons-l10n directory. That keeps the work local, and it also means a partially translated addon is a normal state rather than a failure. ## Conclusion Adopt Scratch Addons if you want community features for the Scratch site and editor without maintaining several separate extensions, and if you are willing to review what each addon injects into the page before enabling it. Do not expect it to work where browser extension APIs are required, because userscripts run in the unprivileged main world where chrome.* is unavailable, and it is not a general-purpose Scratch modification layer outside the addons it ships. Before installing anything, read the addon manifest for the specific addon you intend to enable and check the setting list it exposes, since the extension gives every addon its own settings page entries and every injected script runs with the page's own privileges. ## FAQ ### What is an addon in Scratch Addons? An addon mainly consists of one or more userscripts written in JavaScript or userstyles written in CSS that run on the Scratch website or project editor. Each addon has its own directory containing an addon.json manifest file. ### Why can't Scratch Addons userscripts use chrome.* extension APIs? Userscripts run in the main world, the unprivileged context where chrome.* extension APIs are not available, similar to extension content scripts running in the main world. They instead use the addon.* APIs for utilities such as waiting for elements, listening to settings change events and getting a reference to the Scratch VM object. ### Can I use Scratch Addons addons without installing the browser extension? The documentation says Scratch forks can use the addons, and names TurboWarp and Adacraft as projects whose editors let you use most of the editor addons without installing browser extensions, in the case of TurboWarp Desktop even while offline. ### How do I install Scratch Addons and turn individual features on? The project is distributed through the Chrome Web Store and Firefox Add-ons, and the front page points to both listings. The extension adds a settings page where each addon can be enabled, disabled and configured, and the settings the extension stores are what the addon.* APIs expose to running userscripts. ### What licence does Scratch Addons use and how often is it updated? The project is licensed under GPL-3.0 with the LICENSE file in the repository root. The last push was on 2026-10-18, and the listed releases include v1.45.2 on 2026-04-29, v1.45.1 on 2026-04-25 and v1.45.0 on 2026-04-05, with new versions going to the stores regularly. ## Sources - [License: GPL-3.0](https://github.com/ScratchAddons/ScratchAddons/blob/master/LICENSE) - [Project website](https://scratchaddons.com) - [README](https://github.com/ScratchAddons/ScratchAddons/blob/master/README.md) - [Releases](https://github.com/ScratchAddons/ScratchAddons/releases) - [ScratchAddons/ScratchAddons on GitHub](https://github.com/ScratchAddons/ScratchAddons) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/scratchaddons-scratchaddons