Every Chrome extension developer ends up assembling the same rough stack, usually by trial and error — a manifest tool here, a screenshot resizer there, an analytics setup bolted on after launch when someone finally asks "wait, do we know how many people actually use this?" This is an attempt to lay that stack out in the order you actually need it: build, debug, ship the listing, measure, retain. We built some of the tools mentioned here — we'll say so plainly where that's true, and we'll be just as plain about where a general-purpose tool is simply the right call.
Building the extension
Manifest V3 is where most new extensions start losing time before they've written a line of feature code. The manifest schema has enough required fields, permission quirks, and deprecated V2 leftovers that getting it right by hand is slower than it should be. Two approaches cover most developers:
Hand-write it against the docs. Fine if you've shipped a few extensions already and know the shape of manifest.json from memory. Slower for anyone building their first one, and error-prone around permission declarations — it's easy to request <all_urls> when a narrower host pattern would do, which shows up as a scarier install warning than your extension needs.
Use a generator. Our own Manifest Generator builds a valid MV3 manifest from a visual form, with a live preview and permission trust warnings so you can see the install prompt your users will see before you ship it. It's free and runs client-side — no signup, nothing sent to a server. Worth being honest here: it's built for getting a correct manifest quickly, not for advanced edge cases like unusual content-script matching patterns, which you'll still want to read the Chrome docs for.
Once you have a manifest — generated or hand-written — run it through a validator before you rely on it. Our Manifest Validator checks for missing required fields, Manifest V2 leftovers, host patterns in the wrong place, and the exact permission warnings each entry will trigger for users. It catches the class of bug that's invisible in development (the manifest loads fine locally) and only shows up as a rejected Web Store submission or a scarier-than-expected install prompt.
For everything else — boilerplate and local development — the general tooling is genuinely good and there's no reason to reinvent it:
- Starter templates. Vite-based extension boilerplates (several actively maintained ones exist on GitHub) handle the build pipeline, TypeScript setup, and hot-reload wiring so you're not hand-rolling a bundler config for a browser extension.
chrome://extensionsdeveloper mode with "Load unpacked." This remains the fastest local-reload loop for most people — build, click reload, test. Some starter templates layer file-watching on top of this to auto-reload on save.- A
.gitignorethat actually excludes your build output and any local secrets. Small thing, commonly forgotten on a first extension.
Debugging and testing
Chrome DevTools works differently for extensions than for regular web pages, and it's worth knowing the extension-specific entry points before you're debugging blind.
The service worker inspector. Manifest V3 background scripts run as service workers, not persistent background pages, which means they can go idle and terminate between events. Go to chrome://extensions, enable developer mode, and click "service worker" under your extension to open a dedicated DevTools instance attached to it. This is where you'll catch bugs that only reproduce because the service worker restarted mid-flow — a surprisingly common class of MV3 bug that doesn't exist in the same form under the old persistent-background-page model.
Inspecting popup and content-script contexts separately. Your popup has its own DevTools (right-click the popup while it's open, "Inspect"), and content scripts run in the context of the page they're injected into, so they show up in that page's regular DevTools console — not your extension's. Mixing these up wastes time; know which console you're supposed to be looking at before you start debugging.
chrome://extensions/?errors=<id> surfaces runtime errors Chrome has caught for a specific extension, including ones that happened when no DevTools panel was open. Worth checking after any test session, since some errors won't print anywhere else.
General practice that matters more than tooling: test the uninstall-and-reinstall path, not just the happy path. Extensions accumulate state in chrome.storage, and a stale-state bug on reinstall is a common source of one-star reviews that never show up in a normal development loop.
The Web Store listing
Getting the code right doesn't matter much if the listing doesn't convert. Screenshots, promo tiles, and the store icon each have exact size requirements — 1280×800 or 640×400 for screenshots, a 440×280 small promo tile, 128×128 for the store icon — and getting any of them wrong means either a rejected submission or a listing that looks noticeably worse than competitors who got the pixels right.
Our Web Store Asset Resizer takes one source image and exports it into every required Web Store size — icons, promo tiles, and screenshots — entirely in the browser. It solves the sizing mechanics honestly and nothing more: it doesn't write your copy, pick your keywords, or design your screenshot layout for you. For the strategy behind what actually makes a listing rank and convert — the name, the description, which screenshots to lead with, how ratings and uninstalls factor into ranking — we cover that in full in the Chrome Web Store Optimization guide. The two are meant to be used together: sizing is the mechanical last step, not the strategy.
Analytics
Most extension developers ship with no analytics at all, then bolt something on after launch once growth stalls and nobody can say why. It's worth deciding what to measure before you need the answer, not after.
At minimum, track:
- Activation — did a new install do the thing your extension exists to do, at least once?
- Weekly active users relative to installs — the Chrome Web Store dashboard gives you WAU and install counts, but not the ratio between them, which is the number that actually tells you if people are sticking around.
- Feature usage, if your extension has more than one — which features get used, which are dead weight.
- Uninstall rate over time — trending up after a release is a strong signal something in that release broke something for someone.
The Web Store developer dashboard gives you the raw install/uninstall/WAU counts and nothing else — no cohorts, no reasons, no funnels. We go deeper into exactly what the dashboard does and doesn't tell you, and how to build the analytics layer on top of it, in the Chrome extension analytics guide.
Retention and feedback
This is the part of the stack most extensions skip entirely, and it's the one with the clearest return for the least effort. Chrome gives you exactly one hook for hearing from users who are leaving: chrome.runtime.setUninstallURL(). Call it once in your background script, point it at a page you control, and Chrome opens that page automatically the instant someone uninstalls — one line of code, one moment of attention from a user who's already decided to go. We walk through the implementation, constraints, and what to put on that page in the setUninstallURL tutorial.
Capturing the uninstall reason is half of the retention layer. The other half is giving users who do stick around a way to ask for things and see what you're building next, so the good ideas don't just evaporate into a review section nobody reads twice. UserFeed is our product for this specific gap — a hosted uninstall feedback form, a feedback portal for feature requests, and a public roadmap, built for extension developers rather than adapted from a general SaaS feedback tool. It's the one product recommendation in this post that's ours; we're including it because it's the one piece of this stack we built specifically because nothing else fit an extension's shape well.
Putting the stack together
None of these tools matter individually as much as using them in the right order. A manifest built and validated correctly avoids a rejected submission. A listing sized and optimized correctly gets found. Analytics tells you whether what you shipped is working. And an uninstall hook plus a feedback portal is the only way to find out why it isn't, from the users who never bothered to leave a review. Start with the free tools if you're missing pieces, and treat retention as part of the build — not an afterthought you get to once growth has already stalled.
Last updated: August 2026