We have published six extensions of our own across Chrome, Edge and Firefox. The building is rarely the hard part. The store review is where projects lose weeks, and almost always for reasons that have nothing to do with whether the code works.
If you are planning an extension, this is what the review is actually looking at.
It is a permissions review, not a code review
No human reads your source line by line. What gets scrutinised is the gap between what you asked for and what you visibly need.
Every permission in your manifest is a claim. <all_urls> says your extension needs to read and change every page the user visits. tabs says you need to see what they have open. storage is unremarkable; webRequest is not. If a reviewer cannot look at your listing screenshots and understand in one sentence why a permission is necessary, that is where the rejection comes from.
The practical consequence is that permissions are a design decision, not an implementation detail. An extension that works on one domain and asks for one host permission clears review quickly. The same functionality built to run everywhere, “in case we expand later,” invites a conversation you did not budget for.
Ask for what today’s version needs. Widening scope later is a new review; starting wide is a review you may not pass at all.
The privacy disclosures are a separate piece of work
Chrome requires you to declare what data your extension collects, tick a set of certifications about how it is used, and — this is the part that surprises people — have a privacy policy at a public URL if you handle anything at all.
The failure mode is not lying. It is a mismatch: the form says the extension collects nothing, and the code sends an analytics ping. Or the privacy policy is generic boilerplate that mentions data types the extension never touches. Either way it reads as carelessness, and it holds the listing.
Budget real time for this. Writing an accurate privacy policy for an extension is a couple of hours, and it has to be true, because the reviewer can read your code and compare.
The three stores are not the same review
They are close enough to lull you and different enough to cost you.
- Chrome is the strictest on permissions justification and the most consequential, because
Edge and most Chromium browsers take a Chrome-format package.
- Edge accepts the same package but runs its own certification pass, on its own timetable.
Passing Chrome does not mean passing Edge on the same day.
- Firefox is a different manifest lineage and a different signing process, and it asks for
something the others do not: if your submitted code is minified or bundled, you must supply the source and build instructions so a reviewer can reproduce your package. A build pipeline nobody can run from a clean checkout is a rejection.
Plan for three submissions with three timelines, not one submission published three times.
What actually costs the weeks
In our experience, almost nothing that stalls a listing is a bug:
1. A permission nobody can justify in a sentence 2. A privacy disclosure that does not match the code 3. Screenshots and a description that promise more than the extension does 4. A Firefox build a reviewer cannot reproduce
All four are decisions made before a line is written, which is why we scope extensions with the manifest first and the features second.
The part worth knowing before you commission one
An extension is a small piece of software with an unusually large amount of process around it. The build might be two to four weeks; the store path is its own project, and it does not compress by adding people.
If someone quotes you a build with no line for review, submission and disclosure, they are quoting half the job.
We scope the manifest before the features, and store submission is inside our Browser Extension Build, not an extra. Six of our own are published and running — you can install them from JSKAPPS and see what you would be buying.