Toolkit for YNAB: a browser extension that adds options to the YNAB web app

The problem Toolkit for YNAB solves, and who it is actually for

YNAB shipped a new web version, and power users of the older versions wanted behaviour the new app did not offer. The README is blunt about the reasoning: "Rather than ask the YNAB team to implement these features, let's just do it ourselves!" That sentence is the whole design brief. The project is a browser extension that runs alongside the YNAB web application and adds options on top of it.

The audience is narrow and specific. It is for people who budget in the YNAB web app in a desktop browser and who find one or more of its defaults annoying enough to install an extension. It is not for people on mobile, and it is not for people who want a separate budgeting application. The extension does not store your budget; it changes how the YNAB page in front of you behaves.

The feature list lives in docs/feature-list.md and is also rendered on the extension's options page after installation. That second location matters more than the first, because it is where you actually turn individual features on and off, and it is the authoritative view of what your installed build supports.

How the extension is put together: Web Extensions, Babel and Webpack

The build rests on three tools, and the README names them explicitly. ESLint checks code style against the project's guide. Babel transpiles ES2015 back to ES5 so newer JavaScript syntax runs in browsers that do not support it natively. Webpack bundles the entry points for all Web Extension pages (background, popup, options and content scripts) into single files and manages most of the build process.

The source that matters to a feature developer sits in src/extension/features. Under that directory are subdirectories representing sections of the YNAB application, and the README tells contributors to pick the folder matching the part of YNAB their feature touches and build there. A feature is therefore scoped to a region of the host page rather than being a global hook.

The README also describes a framework change. The old framework required a lot of boilerplate in every feature; the new one leans on ES6 features to remove that burden. That is a maintainability argument, not a user-visible one, but it explains why the repository is TypeScript-heavy and why the feature directories are the entry point for contributions.

One build constraint is worth repeating because it wastes real time: the README states that your code editor must use Unix style line feeds, or the build will fail. This primarily affects contributors on Windows.

Installing Toolkit for YNAB and trying it for the first time

If you just want to use it, the README points at three store listings and nothing else. Chrome users get it from the Chrome Web Store, Firefox users from the Firefox Add-on Repository, and Edge users from the Microsoft Edge Add-ons store. There is no self-hosted or Docker path documented.

After installation, the options page is where you configure features to be on or off. Start there rather than hunting through the YNAB interface: the README says the full feature list is available on the options page of the extension once installed.

If you want to build from source instead, the README gives these prerequisites and steps. Node.js must be at least 18.12.1 and Yarn at least v1.10.0. On macOS the README suggests brew plus xcode-select --install; on Windows it suggests Chocolatey for both node and yarn.

yarn install
yarn build:development

The first command installs dependencies. The second builds the Toolkit. While developing, the README notes that yarn watch monitors the project directory and reruns the development build automatically, and that yarn watch:webpack compiles only your code changes without regenerating indexes, which can noticeably speed things up when you are not adding new features.

Loading the result into Chrome is a manual step. The built extension appears in the dist/extension folder; you open chrome://extensions, turn on Developer mode, click Load unpacked, and select that folder. The README adds that you may need to reload the plugin if it was already installed.

yarn global add web-ext
yarn run manifest:firefox && web-ext run --source-dir dist/extension/

That is the Firefox path from the README. It installs web-ext globally, applies the Firefox manifest overrides, then launches Firefox against the built directory. The README warns that PATH must include the Yarn global bin directory, and shows a ~/.bash_profile line for it. It also documents web-ext run --no-reload --source-dir dist/extension/ if you want to disable automatic reloading.

The maintenance mode notice is the first thing to read

The README opens with a heading that says Maintenance Mode (Looking for Maintainers), followed by a paragraph stating that the Toolkit for YNAB is officially in maintenance mode, that updates will be much more infrequent and will likely only contain bug fixes and not new features, and that the team is looking for new maintainers to take on approving and releasing updates. Contact is directed to Josh Madewell on the project's Discord.

Read that as a product statement rather than a formality. A bug-fix-only policy means the feature set you see today is roughly the feature set you keep. If a YNAB interface change breaks a feature, a fix is plausible. If you want a feature that does not exist, the README is telling you not to expect one from the current maintainers.

The release history is consistent with that framing. The repository is not archived, and the most recent release, v3.22.5, is dated 2026-08-04, with v3.22.4 on 2026-07-28 and v3.22.3 on 2026-06-22. Those are patch-level version bumps, which matches a bug-fix cadence rather than a feature cadence. Note also that package.json declares version 3.23.0 while the newest listed release is v3.22.5, so the manifest version and the release tag are not the same number at any given moment.

The practical risk is dependency on a host application you do not control. Everything this extension does happens on top of the YNAB web app. When that app changes its markup or behaviour, features built against the old structure can stop working, and the maintenance-mode policy limits how fast anyone will notice or fix it.

Safari is not supported, and the README explains why

The extension is built using Browser (Web) Extension APIs. The README states plainly that since the extension is built with Web Extensions and Safari does not support that, the extension itself is not supported on Safari. It then adds that when or if Safari decides to support Web Extensions, the project will do what it can to provide support.

That is a hard boundary, not a gap in the documentation. If Safari is your browser, this project is the wrong tool today, and no configuration option changes that. The README lists Chrome, Firefox and Edge as the supported targets, and those are the three store links it provides.

There is a build:ios script in package.json and a manifest:ios script that applies iOS manifest overrides, which shows some iOS-oriented build plumbing exists in the repository. The README does not document an iOS distribution path or a store listing for it, so treat those scripts as build tooling rather than a supported product surface. The README's own statement about Safari remains the accurate summary of browser support.

One more limitation follows from the same architecture. Web Extensions run inside the browser, so the extension's behaviour is tied to the browser profile where it is installed. Nothing in the README describes a server component, a sync service, or a way to share configuration across machines.

How it compares with asking YNAB for the feature, or using userscripts

The README's motivation section sets up the alternative directly. The choice it names is between requesting features from the YNAB team and implementing them in a browser extension. Those two paths differ in who carries the maintenance cost. A feature shipped by YNAB is maintained by YNAB and works across every platform YNAB supports, including mobile. A feature shipped by this extension is maintained by volunteers, works only in the three supported desktop browsers, and breaks when the host page changes.

A second alternative is a personal userscript. A userscript is written by the person who needs it, so it can target exactly one annoyance with no review process and no style guide. The trade-off is that you own every breakage, you get no options page, and you get no shared feature set. Toolkit for YNAB is the opposite bet: a large shared catalogue of features, at the cost of a slower release process and a maintenance-mode roadmap.

The repository's contribution rules show where that cost lands. The README says a large number of contributors each brought their own style, that navigating features became hard, and that the team voted to follow the AirBNB style guide and enforce it with ESLint. Contributions are welcome but the README asks you to check the roadmap and post on the GitHub issues board so effort is not duplicated. That is a coordinated project, not a place to drop a one-off patch.

Licence, upgrade cost and what maintenance mode means for your setup

The project is MIT licensed. For most users that is uninteresting, because you install a packaged extension rather than redistribute it. If you fork it, ship a modified build, or vendor the source into an internal tool, MIT is permissive and the practical obligation is preserving the licence text. This is a description of the licence identifier, not legal advice; read LICENSE in the repository if the details matter to you.

Upgrade cost has two parts. The first is the extension version: store builds update through the browser, and the release history shows patch releases arriving on the order of weeks to a couple of months apart. The second is the host application. Because the extension operates on the YNAB web app, a YNAB-side change is the event most likely to require an update, and the README's maintenance-mode notice caps how quickly that update arrives.

If you build from source, the upgrade path is the same set of commands you used the first time. yarn install refreshes dependencies, and yarn build:development rebuilds into dist/extension, which you reload from chrome://extensions. The README's note about reloading an already-installed plugin applies on every rebuild. For Firefox, yarn run manifest:firefox && web-ext run --source-dir dist/extension/ is the documented loop.

Editorial conclusion

Adopt it if you already use the YNAB web app in Chrome, Firefox or Edge and you want options YNAB itself does not expose. Do not adopt it if you need Safari, or if you expect new features: the README states the project is in maintenance mode and that updates will likely contain only bug fixes. Before installing, open the options page and check that the specific features you want are still listed in docs/feature-list.md, because a feature you cannot find there will not be added for you.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes