How to Ship a Browser Extension as a Side Project

To ship a browser extension as a side project, pick one small job on one site or workflow, build it on Manifest V3 with as few permissions as possible, fill in the Chrome Web Store's Privacy tab honestly, and submit a plain, accurate listing. Then port it to Firefox with a few manifest additions, ship updates without adding scary permissions, and check the host site weekly so it doesn't quietly break. Two weekends to build, an evening to submit, a short weekly check after that.

This guide is for people with a day job who want a small extension in the stores without getting stuck in review. Store rules and API facts were checked against Chrome for Developers, MDN and Mozilla's Extension Workshop in October 2026. The example near the end is made up, and so are its numbers.

Why do browser extensions suit nights and weekends?

An extension lives where your users already spend their day, which has nice side effects when your hours are limited:

• Small surface. One button, one popup, one script. You can hold it all in your head after a week away.

• Built-in discovery. Each browser has a store with search, so you don't start from zero traffic.

• Often no servers. If it stores data locally and talks to nothing, there's no hosting bill and nothing to wake you at 3am.

• Familiar tools. It's HTML, CSS and JavaScript.

When it's a bad fit: if the idea needs accounts, syncing or a backend anyway, the extension is a thin front for a web app and you're signing up for two products.

What kind of extension idea survives a day job?

The ideas that last are boring in a good way: one job, on one site or workflow. "Save this listing with my note." "Count the words I selected." "Hide the sidebar on this one tool."

The Chrome Web Store pushes you that way too. Its policies say an extension "must have a single purpose that is narrow and easy to understand," and that clearly separate features belong in separate extensions.

One warning from experience rather than data: extensions that read or change a specific website depend on that site's HTML, and that's the most common way I've seen small extensions die. The site renames a class, your script finds nothing, and users leave a one-star review before you notice. Pick a site that changes slowly and plan a weekly check.

If you have several ideas, cut each one down to what you could ship in two weekends, and build the one that still feels useful at that size.

What is Manifest V3, in plain words?

Manifest V3 is the current format for Chrome extensions. Chrome's extension getting started guide splits an extension into a few parts:

• The manifest. manifest.json in the root folder, the only required file. It holds the name, version, permissions and which scripts run where.

• A service worker. The background part that reacts to browser events, with no access to the page. The service worker lifecycle docs say Chrome normally stops it after 30 seconds of inactivity and global variables are lost, so save state with storage.

• Content scripts. JavaScript that runs in a web page and can read or change it, in an "isolated world" so your variables don't clash with the page's.

• The action. Your toolbar icon, which can run code or open a popup.

The rule that trips people up: all logic must ship inside the package. You can fetch data, but not download and run code. The policies list running eval() on a string fetched from a remote source as a common violation.

Here's the whole manifest for the made-up Roomtuck example below. No background script, because it doesn't need one.

{
  "manifest_version": 3,
  "name": "Roomtuck",
  "version": "1.0.0",
  "description": "Save rental listings to a private shortlist with your own notes. Nothing leaves your browser.",
  "permissions": ["storage"],
  "content_scripts": [{
    "matches": ["https://rentals.example/listing/*"],
    "js": ["content.js"]
  }],
  "action": { "default_popup": "popup.html" }
}

How few permissions can you get away with?

Fewer than you think, and it matters for review and for users. Chrome's review process page says reviews may take longer for broad host permissions like <all_urls> or sensitive ones like tabs and downloads. The policies say to request the narrowest permissions possible and not to "future proof" with ones you might need later. Users see the same thing as an install warning.

1. Use activeTab when the user starts things with a click. Chrome's activeTab documentation says it grants temporary access to the current tab when the user invokes your extension, ends when they leave that site or close the tab, and shows no install warning. Pair it with scripting to inject code on click.

2. Match only the pages you need. One site's listing pages means one pattern, not https://*/*.

3. Make extras optional. Chrome's guide to declaring permissions covers optional_permissions and optional_host_permissions, granted at runtime. Ask when someone turns on the feature that needs it.

Before submitting, delete every permission your code doesn't use. "Requesting a permission but not using it" is a listed reason for the excessive permissions rejection.

What do you need before your first Chrome Web Store submission?

Before you can publish a Chrome extension, give the account side one evening. From Chrome's developer registration page, the account setup docs and the policies:

• A one-time registration fee. The register page doesn't print the amount. Google's Chromium Blog post on the registration flow put it at $5.00, and the developer agreement says Google sets it, so check the dashboard before paying.

• A supported country. Registration only works in the countries listed on that page.

• A dedicated email. Google suggests a new address just for publishing, and you can't change it later. Keep it off your work account.

• 2-Step Verification, required before you publish or update, plus a verified contact email and a publisher name. A physical address is only needed if your item offers purchases or subscriptions.

The publish docs also say new publishers start with a maximum of two published extensions. Don't burn a slot on a test.

What goes in the Privacy tab, and do you need a privacy policy?

Chrome's guide to filling out the privacy fields asks for:

• Single purpose. A sentence or two that matches your listing.

• Permission justifications. One line per permission. Can't write the line? Delete the permission.

• Remote code. Say no, and make sure it's true.

• Data usage. Tick what user data you collect and certify you follow the store's rules.

• Privacy policy link.

The Chrome Web Store program policies say that if your product handles any user data, you must post an accurate, up to date privacy policy and link it in the designated field. Their Limited Use section adds that data can only serve your disclosed single purpose, and can't be sold or used for personalized ads. Keep the policy short and true: what you store, where, and whether anything leaves the device. That's the store requirement; it isn't legal advice.

How do you write a store listing that passes review?

The bar is "a stranger gets what this does in five seconds."

• Short description. It comes from description in your manifest; Chrome's manifest description reference caps it at 132 characters of plain text.

• Detailed description. One plain sentence on what it does, then the main features.

• Images. A 128x128 icon and at least one 1280x800 screenshot of it doing its job. A blank description or missing icon or screenshots means rejection.

• No keyword stuffing. The policies call out lists of sites or brands, lists of regions, repeating a keyword more than five times, and anonymous testimonials.

What happens during Chrome Web Store review?

Here's what Chrome's docs say on timing, and nothing more: most reviews finish within a few days, some take up to a few weeks, and if you're pending more than three weeks, contact developer support. New developers, new extensions, dangerous permissions and significant code changes can all mean a closer look, so your first submission may be a slower one. Plan the launch after approval.

When you submit, you can untick automatic publishing and publish manually after it passes; the publish docs give you up to 30 days. Spot a bug while waiting? Cancel the review, upload a fixed package, resubmit. Want real users first? Add trusted tester emails on your account and set the item to private for them.

What usually gets a first extension rejected?

Chrome's troubleshooting page for store violations gives each violation a two-word ID that appears in the rejection email. The likely ones for a small project:

• Yellow Magnesium, functionality not working. Often a file named in manifest.json missing from the zip, or Background.js versus background.js. Test the exact zip you upload.

• Purple Potassium, excessive permissions. Unused or broader than needed.

• Yellow Zinc, missing metadata. No icon, screenshot or meaningful description.

• Purple Lithium, privacy policy. Missing, broken link, or pasted into the description instead of the designated field.

• Blue Argon, remote code. Scripts loaded from outside your package.

Fix exactly what the email names and resubmit. The policies allow one appeal per violation, so save it for when you're sure the reviewer is wrong.

Should you ship to Firefox too?

Usually yes, and it's less work than it used to be:

• The namespace. Firefox uses browser.*. Chrome's browser namespace guide says all extension APIs are also under browser from Chrome 148, alongside chrome.*, and suggests new extensions set minimum_chrome_version to 148 and use browser everywhere.

• The background script. MDN's background manifest key reference says Firefox doesn't support background.service_worker and uses background.scripts. List the same file under both keys and each browser picks its own.

• An ID and a data declaration. MDN's browser_specific_settings reference says Manifest V3 extensions must set their own ID to be signed, and Mozilla's built-in data consent guide says new extensions since November 3, 2025 must state what data they collect or transmit, or "none".

For Roomtuck, that's six lines (Chrome ignores this key):

"browser_specific_settings": {
  "gecko": {
    "id": "@roomtuck",
    "data_collection_permissions": { "required": ["none"] }
  }
}

To publish a Firefox add-on, follow the Extension Workshop guide to submitting an add-on: sign in to the add-ons site with a Mozilla account, upload your zip, pass the validator, write a name, summary and description. A privacy policy is required if any data is transmitted from the user's device. A listed add-on is published on submission, though it may still be reviewed later.

If you bundle or minify, Mozilla's source code submission rules require your source plus build instructions, with open source build tools that run locally and your lockfile. For a small extension, the easy fix is not to minify; Mozilla notes the performance gain is small for locally loaded code.

Edge in one line: Microsoft's guide to publishing an Edge extension runs through Partner Center with a similar privacy page and says certification can take up to seven business days.

How do you ship updates without breaking users?

Chrome's guide to updating a store item says updates get essentially the same review as new items. The rules that matter:

• Bump the version every time. Each version must be larger than the last.

• Treat new permissions as breaking. Chrome's permission warning guidelines say an update that adds a warning-triggering permission disables the extension until the user accepts. Use optional permissions instead.

• No staged rollout yet. Percentage rollout only appears above 10,000 seven-day active users, so every update reaches everyone. Test the packed build first.

• Know the rollback. The update docs point to a store rollback for bad releases.

How do you keep it maintainable with a day job?

The host site changing is a bigger risk than your own code. A weekly routine of about 20 minutes (my estimate, not a measurement):

1. Keep a tiny test page. Save a copy of the HTML your content script expects in a test/ folder. When something breaks, diff it against the live page.

2. Check the real site weekly. Same day, use the extension once.

3. Fail out loud. If the script can't find its element, show "this page changed, an update is coming" instead of silence.

4. Keep selectors in one file, and answer reviews and support emails in the same weekly slot.

How do you get your first users?

Store search helps if your name and short description say plainly what it does. Beyond that: one community where people with that exact problem hang out, and a link from your own site. Do one channel weekly rather than everywhere once; the SideHunt guide to picking one weekly distribution habit for a side project covers how.

If the extension is really a doorway to a bigger product, read IndieHunt's playbook on building a free tool that sends signups to your indie product. Just note that an extension whose only job is opening your website breaks the store's redirection rule, and fake or incentivized reviews and installs are banned.

Can you make money from an extension?

Yes, but payments are their own project. Two store rules: if users must pay for basic functionality, the description must say so, and items offering purchases need a physical address on the account. For the rest, see the SideHunt guide on starting to charge for a side project while you have a day job. Ship free first and see if people keep it installed.

A made-up example: Odalys and Roomtuck

Everything here is made up: the person, the extension, the site and every number.

Odalys, a payroll analyst, spent a month apartment hunting on one big listings site with a messy spreadsheet of links and notes like "loud street, ask about parking." She built Roomtuck: a "Tuck" button on each listing page that saves the title, price, link and a note to local storage, plus a popup with the shortlist.

• Weekend one: content script, button, storage. Permissions: storage and one content script pattern. No background script, no server.

• Weekend two: the popup, plain-text export, the "this page changed" message, and a saved listing page in test/.

• One evening: registration, 2-Step Verification, icon, two screenshots, and a one-paragraph privacy page. Unsure whether locally saved notes count as user data, she published a page saying what's stored and that nothing leaves the browser rather than guess.

• Review: rejected for excessive permissions because tabs was left over from an experiment. She removed it and passed on the second try.

• Firefox: added the six-line block and submitted the same zip.

Six weeks in, Roomtuck has 140 users, mostly from one post in a renters' forum. The site redesigned its price block once; her Sunday check caught it and the fix took 15 minutes.

A pre-submission checklist

Common traps

• Asking for every site. Start with activeTab or one site pattern.

• State in global variables. The service worker stops when idle and takes them with it.

• Adding a warning permission in an update. Existing users get a disabled extension.

• Minifying for no reason. Harder reviews, and Firefox will want your source.

• Announcing before approval. Use deferred publishing and announce once it's live.

FAQ

How long does Chrome Web Store review take?

Chrome's review docs say most reviews finish within a few days but can take up to a few weeks, and to contact developer support after more than three weeks pending. There's no guaranteed time, so don't plan as if there were.

Do I need a privacy policy for a simple extension?

For Chrome, yes if it handles any user data, linked in the designated dashboard field. For Firefox, yes if any data is transmitted from the user's device. If unsure, a short honest page about what you store costs ten minutes.

Should I build for Firefox at the same time?

Build for both from day one, since browser.* works in current Chrome and the manifest differences are small. My rule of thumb: submit to Firefox after the Chrome version passes review and a few real users have tried it, so you fix early bugs in one place.

Ship it, then launch it

Pick one job. Write a manifest with one or two permissions. Test the zip, fill in the Privacy tab honestly, submit with deferred publishing on, and add the Firefox block while you wait. That's a browser extension side project shipped in a couple of weekends, with upkeep you can actually keep.

Once it's live, launch it on SideHunt, where other builders with day jobs share what they shipped on nights and weekends.