What is a Chrome extension boilerplate?

A Chrome extension boilerplate is a pre-built starter project that gives you a working Manifest V3 extension with the tedious plumbing already done: a bundler and hot-reload setup, TypeScript configuration, a popup UI, an options/settings page, content scripts that run on web pages, a background service worker, and cross-browser build output. Paid starter kits add the parts that turn an extension into a product — authentication, a storage and sync layer, a backend or SaaS connection, and payment/licensing so you can charge users. It saves you from hand-writing the manifest, wiring up the build, and relearning the quirks of the extension APIs every time you start a new project.

WXT vs Plasmo vs CRXJS — which should I use in 2026?

For most new projects in 2026 the consensus pick is WXT: it is framework-agnostic, built on Vite, and produces cross-browser output for Chrome, Firefox, Safari and Edge from one codebase, with auto-imports and a module system. Plasmo is the more opinionated option and still the smoothest path if your extension injects React UI directly into pages via its content-script UI feature, but it has effectively slowed to maintenance mode (its last release was September 2025) and relies on the Parcel bundler. CRXJS is a thin Vite plugin rather than a full framework — great hot reloading and close to plain Vite, but realistically Chromium-only and it gives you no built-in storage or messaging APIs. Choose WXT for multi-browser or conventional setups, Plasmo for React-heavy in-page UI, CRXJS if you only target Chrome and want minimal abstraction.

Do I still need to worry about Manifest V3?

Manifest V3 is no longer optional — Manifest V2 has been fully deprecated and Chrome disables remaining MV2 extensions, so any boilerplate you buy must target MV3. The practical consequences are that background pages are now ephemeral service workers (they spin up and down, so you cannot keep long-lived state in memory), blocking network interception via webRequest is replaced by declarativeNetRequest, and remotely hosted code is banned (everything must be bundled). A current boilerplate handles these for you: a service worker with proper lifecycle handling, chrome.storage for persistence instead of in-memory globals, and a build that bundles all code locally. If a template still talks about background pages or MV2, it is out of date and will be rejected from the Web Store.

How do Chrome extensions make money?

The proven models are: a freemium extension with a paid Pro tier unlocked by a license (ExtensionPay and Stripe are the common tools), a subscription tied to a connected SaaS backend, a one-time purchase license key, and — for audience-building — affiliate links or a companion web app the extension drives traffic to. Licensing is the part most free boilerplates skip, so a paid starter that already wires ExtensionPay or Stripe checkout plus license validation in the service worker is worth a premium. Avoid relying on the Chrome Web Store's own payments — Google shut that down years ago, so billing always lives in your own stack or a third-party licensing service.

Best Chrome Extension Boilerplates to Buy in 2026: Buyer's Guide

Q: Should I build a Chrome extension from scratch or buy a boilerplate?

Buy a boilerplate if you want to ship a real product in days and the starter already includes the parts that are tedious and easy to get wrong — the MV3 service worker, cross-browser build, hot reloading, a typed messaging layer between content script and background, auth, and licensing. Build from scratch only if your extension is genuinely tiny (a single content script that does one thing) where a full framework is overkill, or if you have unusual requirements no template can bend to. For most indie makers the economics are clear: a quality extension starter costs a fraction of the week-plus you would spend relearning extension plumbing, and the time you keep goes into the niche and the feature that makes people install it.

Chrome extensions are having a moment with indie makers, and the reason is the same leverage that made directory sites and micro-SaaS popular: a small, focused tool that lives in the browser, solves one annoying problem, and can be monetized with a Pro tier. AI side-panels, price trackers, writing assistants, SEO inspectors, tab managers — a single developer can build and ship one in a weekend and charge for it.

The catch is that extension development has more sharp edges than a normal web app. Manifest V3 changed how background code works, the APIs are quirky, the build tooling is its own world, and shipping to Chrome, Firefox and Edge from one codebase is fiddly. That is exactly why a good boilerplate earns its price: it absorbs the plumbing so you spend your time on the feature, not the manifest.

A Chrome extension boilerplate absorbs the Manifest V3 plumbing so you build the feature, not the scaffolding

This guide covers what a modern extension boilerplate must include, how to choose between the three frameworks that matter in 2026, the categories of paid starter kits worth buying, and how to monetize what you ship. If you are weighing an extension against adjacent product shapes, our guides to the best SaaS boilerplate templates and desktop apps with Tauri vs Electron map the neighbours an extension often sits next to.

The Framework Decision Comes First

Unlike a Next.js app where the framework is a given, the first real choice for an extension is which build framework sits under it. Your boilerplate's value is largely determined by this, so understand the three that matter before you spend a dollar.

Framework	Best for	Watch out for
WXT	New projects, multi-browser, any UI framework	Youngest of the three (but actively maintained)
Plasmo	React UI injected into pages (content-script UI)	Effectively maintenance mode; Parcel bundler
CRXJS	Thin Vite plugin, Chromium-only, minimal abstraction	No built-in storage/messaging APIs; you add them

WXT — the 2026 default

For most new extensions, WXT is the consensus recommendation. It is framework-agnostic (React, Vue, Svelte, or vanilla), built on Vite, and produces cross-browser output for Chrome, Firefox, Safari and Edge from one codebase — it handles the MV2/MV3 and Chromium/Firefox differences for you. It adds auto-imports, a reusable module system, and a file-based convention for entrypoints. A boilerplate built on WXT is the safest bet for something you intend to maintain and ship to multiple stores.

Plasmo — React content-script UI

Plasmo pioneered the convention-heavy, "it just generates the manifest from your code" approach, and its standout feature is CSUI — Content Script UI — which lets you render React components directly into a host page cleanly. If your extension's whole point is injecting a rich UI overlay onto other sites, Plasmo is still the smoothest path. The honest caveat for 2026: its release cadence has slowed (last release September 2025) and the team's attention shifted to commercial products, so treat it as mature-but-quiet and check its commit activity before committing a long-lived project to it.

CRXJS — a Vite plugin, not a framework

CRXJS (the @crxjs/vite-plugin) is the lightweight option: it is a Vite plugin that gives you excellent hot reloading for the popup, options page and content scripts, and keeps you close to plain Vite with almost no abstraction. The trade-offs are that it is realistically Chromium-only and gives you nothing built-in for storage or messaging — you write those yourself. After an uneven period, new maintainers took it over in mid-2025 and a v2 release landed in early 2026. Pick it if you only target Chrome and want minimal magic.

The buying rule: a boilerplate's framework should match your extension. Multi-browser or a conventional popup/options/content-script layout → WXT. React UI injected into pages → Plasmo. Chromium-only and you like Vite bare → CRXJS. A starter that is just a hand-rolled manifest.json with webpack glued on and no HMR is a step backwards from all three — avoid it.

What Every Modern Boilerplate Must Include

Regardless of framework, a production-ready extension starter has to cover the non-negotiables. Here is what separates a real boilerplate from a styled hello-world.

Manifest V3, done correctly

Manifest V2 is dead — Chrome has fully deprecated it and disables remaining MV2 extensions. Your boilerplate must be MV3, and MV3 changes the fundamentals:

Background is an ephemeral service worker, not a persistent page. It spins up and down, so you cannot hold state in memory across events — persist to chrome.storage and rehydrate.

declarativeNetRequest replaces blocking webRequest for modifying or blocking network traffic.

No remotely hosted code. Everything must be bundled into the extension; you cannot eval a script fetched at runtime.

A current starter handles all three: a service worker with correct lifecycle handling, storage-backed persistence, and a build that bundles locally. If the docs mention "background page" or MV2, the template is stale.

A typed messaging layer

Content scripts, the popup, and the service worker run in separate contexts and talk via message passing. This is the part developers get wrong most often. A good boilerplate ships a typed messaging abstraction so a message sent from the content script is type-checked against the handler in the background — no stringly-typed chrome.runtime.sendMessage guesswork. If you want the broader case for typing everything, our take on TypeScript vs JavaScript applies doubly to extensions, where the cross-context plumbing is invisible until it breaks.

Hot reloading and a real build

Reloading an extension by hand after every change is misery. The framework should give you HMR for the popup and options page and auto-reload for content scripts and the service worker. Verify this in the demo or docs — it is the single biggest day-to-day quality-of-life feature.

Popup, options, content script, and a storage/sync layer

The standard surfaces — a popup, an options/settings page, content scripts, and chrome.storage wired to your settings with a small typed wrapper — should all be scaffolded. Bonus points for a settings sync layer that uses chrome.storage.sync so a user's preferences follow them across machines.

Cross-browser output

Even if you launch on Chrome first, Firefox and Edge are cheap incremental audiences — if the build supports them. WXT-based starters give you this nearly for free; others may need a manual port. If reaching multiple stores matters, make it a buying criterion.

// A typed message contract is the backbone of a maintainable extension.
// The boilerplate should ship something like this, not raw sendMessage calls.
type Messages = {
  "GET_SELECTION": { reply: string };
  "SAVE_NOTE": { payload: { text: string }; reply: { id: string } };
};

// content script
const selection = await sendMessage("GET_SELECTION");

// service worker
onMessage("SAVE_NOTE", async ({ text }) => {
  const id = crypto.randomUUID();
  await chrome.storage.local.set({ [`note:${id}`]: text });
  return { id };
});

A boilerplate that cannot express a contract like this — where every message is an untyped string and a typo fails silently — will slow you down the moment the extension grows past one feature.

The Paid Starter Kits Worth Buying

Free boilerplates get you a working MV3 scaffold. Paid starter kits are worth money when they include the parts that turn a scaffold into a product. The categories that sell in 2026:

AI side-panel / assistant extensions

AI assistant extensions that read page context and stream a response are the hottest extension category in 2026

The hottest category. These read page context (selected text, the article, the current URL), send it to an LLM, and stream a response into a side panel or overlay. A quality AI extension starter includes a streaming client, an API-key or backend-proxy pattern (so you are not shipping a provider key in the bundle), rate limiting, and a tidy chat UI. Because the API key must never live in the extension, the good ones route through a backend — which overlaps heavily with AI SaaS templates and LLM app templates. Expect $49–129 for a complete one.

SaaS-connected extensions

An extension that is the browser front-end of a web SaaS: it authenticates against your app, reads and writes the same data, and acts as a capture or quick-action surface (think a clipper, a time tracker, a CRM enricher). The value here is the auth bridge — logging the extension into your existing session cleanly — and a shared types layer with the web app. If you already have a SaaS, this kind of starter is the fastest way to add a browser surface. Price range $79–199, higher when it ships both the extension and a matching web dashboard.

Productivity and content-script tools

Tab managers, writing enhancers, screenshot/annotation tools, form fillers, SEO inspectors. These lean hard on content scripts and in-page UI — the category where Plasmo's CSUI shines. A good starter here includes a robust in-page UI mounting strategy (shadow DOM to avoid host-page CSS bleed), keyboard shortcut handling, and a settings page. $29–79 typically.

Licensing-ready freemium starters

The differentiator that justifies the price: a starter with licensing already wired. Free tier out of the box, a Pro unlock gated by a license validated in the service worker, and checkout via ExtensionPay or Stripe. This is the single most-skipped piece in free boilerplates and the hardest to retrofit, so a starter that nails it is worth a premium on its own.

Monetization: Decide Before You Build

A free extension with no upgrade path is a hobby. The proven models, often stacked:

Freemium with a Pro license. Free core, paid unlock. ExtensionPay is purpose-built for this and handles the checkout + license plumbing; Stripe works too with a bit more wiring.

Subscription via a connected backend. The extension checks subscription status against your SaaS. Best when the extension is one surface of a larger product.

One-time license key. Sell a key, validate it once, unlock forever. Simple and popular for utilities.

Affiliate / traffic to a web app. The extension is free and drives installs or clicks to a monetized companion site.

The one thing that does not work: the Chrome Web Store's own payments — Google removed in-store payments years ago. Billing always lives in your stack or a third-party licensing service, which is precisely why a boilerplate that ships it is valuable.

How to Evaluate Before Buying

Run every candidate through the same checks:

Confirm it is Manifest V3. Grep the docs and the manifest config for V3 and a service worker. Any mention of MV2 or background pages is a hard pass.

Check the framework and its health. WXT, Plasmo or CRXJS — and look at the underlying framework's recent release activity, not just the template's.

Verify hot reloading exists. No HMR/auto-reload is a daily tax you will pay forever.

Look for a typed messaging layer. Raw sendMessage strings everywhere signal a thin wrapper around a tutorial.

Open the demo / load the unpacked build. Does the popup work, does the content script inject, does the options page persist settings?

Find the licensing. Is ExtensionPay or Stripe wired, or is monetization "left as an exercise"?

Check cross-browser output. Does build emit a Firefox/Edge bundle, or is it Chrome-only?

Read the README and look for a loom/video. A real walkthrough tells you the author shipped something real.

The classic dud is a beautiful popup screenshot, an MV2 manifest underneath, no HMR, untyped messaging, and no licensing. It demos fine in a screenshot and collapses the moment you try to grow it into a product.

Build or Buy?

Buy if you want to ship a real extension in days and the starter already includes the tedious, easy-to-get-wrong parts — the MV3 service worker and lifecycle handling, cross-browser build, hot reloading, a typed messaging layer, auth, and licensing. For most indie makers that is the right call: a quality extension starter costs a fraction of the week-plus you would otherwise spend relearning extension plumbing, and the time you keep goes into the niche and the one feature that makes people install it.

Build from scratch only if the extension is genuinely tiny — a single content script that does one thing — where a full framework is overkill, or if you have unusual requirements no template can bend to. If you are still choosing the overall shape of what to build and sell, our guides to vibe-coded projects to build and sell and the best tech stack for web apps help you pick before you commit.

The Bottom Line

A Chrome extension boilerplate is worth buying when it absorbs the plumbing and hands you a product shell, not a hello-world:

Manifest V3 done right — a proper service worker, storage-backed persistence, locally bundled code.

The right framework — WXT for most new projects, Plasmo for React in-page UI, CRXJS for thin Chromium-only builds.

A typed messaging layer and real HMR, so the extension stays maintainable and pleasant to work on as it grows.

Licensing wired to ExtensionPay or Stripe, so you can charge from day one instead of retrofitting billing later.

Get those right and the starter earns its price many times over. The niche and the single feature people install it for are the parts no template can give you — and the parts worth all of your time.

Looking for a production-ready extension starter, SaaS boilerplate or AI template instead of a blank repo? Browse quality-scored code on CodeCudos — every listing is graded on working flows, documentation and code quality — or, if you have built a solid extension boilerplate, list it for sale. For the stacks an extension connects to, see our guides to the best Next.js templates to buy, AI SaaS templates and React Native & Expo templates. And if selling your own code is the goal, start with how to sell code online.