Building a browser extension in 2026 is weirdly harder to research than it is to actually build.
The official docs are split across four browsers. Half the blog posts you find are from the Manifest V2 era and quietly wrong now. And the one tool you need for cross-browser polyfills, or publishing automation, or figuring out why your install funnel leaks, is always buried on page three of a search.
So I stopped re-googling the same 20 links every project and put everything I actually reach for into one place:
github.com/quangpl/awesome-extension-dev
It is a curated list of 120+ tools, frameworks, libraries, and resources for modern extension development, covering Manifest V3, cross-browser work with WXT and Plasmo, build tooling, testing, publishing, security, and growth. Below is a quick tour, organized the way you actually build an extension, not alphabetically.
It is organized by the lifecycle, not the alphabet
Most awesome lists dump 200 links into one scroll. This one follows the path you walk every time: pick a framework, deal with MV3, build the UI, wire messaging, test it, publish it, then grow it. There are 16 sections, but they group into five real stages.
1. Pick your foundation
The Frameworks and Boilerplates section is where most people start, and where most people pick wrong.
- WXT is the default I would hand almost any new project. Vite-based, framework-agnostic (React, Vue, Svelte, Solid, or vanilla), genuinely cross-browser, and actively maintained.
- Plasmo is the React-first option with the biggest pile of existing tutorials, though it has slowed on maintenance.
- CRXJS is a Vite plugin, not a full framework, for people who want minimal magic and full control of their config.
If you want the deep comparison, I wrote a separate breakdown of all three, but the list gives you the links and the one-line "use this when" for each.
2. Survive Manifest V3
The Manifest V3 and Migration section plus Cross-Browser and Polyfills are the ones that save the most pain. Service workers instead of background pages, declarativeNetRequest instead of blocking webRequest, and the chrome.* vs browser.* namespace mess all live here, with the polyfills and migration guides that make them bearable.
3. Build and test the thing
UI and Components, Messaging and Storage, Build Tools and Bundlers, and Testing and Debugging cover the actual coding. Shadow DOM isolation for content scripts, type-safe storage wrappers, and the handful of testing setups that work inside the extension sandbox (which is not the same as testing a normal web app).
4. Ship without losing a weekend
Publishing and Store Automation is small but mighty. The GitHub Actions and CLI tools here turn "manually zip, log into four dashboards, fill out four forms" into one command. If you ship to more than one store, this section pays for itself the first week.
5. Grow, because building is only half the job
Here is the part nobody warns you about. The framework decides how fast you build. It does absolutely nothing for whether anyone finds and installs what you built.
The Chrome Web Store is a discovery black box. New extensions launch invisible, ranking leans heavily on early reviews and on keyword placement in your title and description, and you get almost no signal on where your funnel leaks (impressions, then listing views, then installs, then retention).
So the list has dedicated Analytics and Monetization plus Growth and Store Optimization sections. One of the growth tools in there that I lean on is ExtensionBooster: it handles the unglamorous post-launch stuff, real and store-compliant reviews and installs, market and competitor analytics for your category, showcase pages that double as SEO backlinks, and free listing tools like an icon generator, a screenshot maker, and a promo-tile cropper. Worth a look before your first submission, since you need those listing assets the day you ship anyway.
Also in there
A few sections I find myself opening more than expected:
- AI in Extensions, because half the new extensions launching right now are AI wrappers, and the patterns for calling models from a service worker are not obvious.
- Example Open-Source Extensions, real codebases you can read instead of guessing how production extensions structure things.
- Security and Privacy, the stuff that gets your extension pulled if you ignore it.
- Communities and Newsletters, so you have somewhere to ask when the docs fail you.
It is open source, so make it better
The whole point of an awesome list is that it gets better when more people who actually ship extensions add what they use. If your favorite tool is missing, or something on the list is outdated, open a PR or an issue.
Star or contribute here: github.com/quangpl/awesome-extension-dev
What is the one extension tool you would not build without that you think most people have never heard of? Drop it below, I will add the good ones to the list.
Top comments (0)