What it really takes to publish a browser extension

Every tutorial sells you the same fantasy. A weekend, a manifest.json, a popup — and you publish a Chrome extension with a neat little "published" badge. The coding part of that story is roughly true. Everything after the last commit is where the fantasy quietly dies.

That's the part where your extension actually becomes available to users. I've watched enough extensions go through store review to say it plainly: publishing is not one step.

It's a gauntlet. Three gates, a queue, a reviewer, and a clock that restarts every time you get something wrong. Here's what that gauntlet looks like in 2026.

The scale you're lining up behind

First, some perspective on the queue you're joining. According to Chrome-Stats, which tracks the store continuously, the Chrome Web Store held roughly 303,800 extensions as of August 2026. Mozilla's directory counts over 74,000 Firefox add-ons as of January 2026, and community trackers put the Microsoft Edge add-ons catalog at around 31,000.

One tracker on r/chrome_extensions counted 49,518 new Chrome extensions in a single quarter — more than the entire Edge catalog. Your extension isn't entering a curated gallery. It's entering a queue that gets longer every week, and it's being judged by systems built to cope with that flood.

The production before the upload

Here's what tutorials skip entirely: the upload button is not the first step. It's step thirty.

Before you can even open the developer dashboard, you need to produce a small media production. Four icon sizes (16, 32, 48, 128 pixels for Chrome, a slightly different set for Firefox and Edge). At least one screenshot per store at a minimum of 1280×800 or 1280×720, though the stores recommend more. Chrome asks for promotional tiles — a 440×280 small promo, a 920×680 marquee, and a 1400×560 large marquee — if you ever want to be featured.

Then the copy. A short description (132 characters for Chrome, 250 for Firefox). A detailed description in markdown, ideally with keywords researched against what your competitors rank for. A privacy policy URL that actually matches what your extension does, not a generic template that says "we collect nothing" while your analytics SDK quietly collects everything. A homepage URL. A support URL. A support email.

If you're serious about distribution, you need that copy in more than one language. Chrome Web Store supports 40+ locales, and localized listings convert dramatically better than English-only ones. That's 40 translations of your short description, your detailed description, your changelog, and your screenshots with localized UI.

Then the smaller decisions that turn out to matter. A category selection that determines which browsing surfaces surface your extension. A data declaration that lists every piece of user data you collect — Chrome's privacy disclosure form is not optional, and it must match your privacy policy. An onboarding flow that actually teaches new users what your extension does, because the store listing is marketing, not documentation.

This is a week of work. Conservative estimate. And it happens before you touch the upload button, before the review queue, before the part where you wait.

This is also the part where most developers cut corners — and where the tools that exist specifically for this job earn their keep. The icon generator produces a full store-ready icon set from a prompt or an SVG, plus a promo tile and a paste-ready manifest snippet (2 free AI generations, then credit packs for volume). The SEO optimizer scores your listing copy against top competitors in your niche and suggests keyword, readability, and field-length fixes. The AI visibility tool does the same for AI assistants — scores your copy for discoverability by ChatGPT and Claude, then generates llms.txt and Schema.org JSON-LD for your extension's site. The page generator builds a polished single-page HTML landing site you can deploy anywhere.

None of this is glamorous. None of it is optional. And none of it is what the "publish a Chrome extension in 10 minutes" tutorial mentioned.

Gate one: the manifest is not just config

The first hidden stage happens before you upload anything. The manifest is where most future rejections are already baked in.

Request <all_urls> or the tabs permission when you don't strictly need them and you've done two things at once. You've made every potential user's install dialog scarier, and you've flagged your submission for closer inspection.

Google's own review documentation lists "dangerous permission requests" among the signals that make a reviewer examine an extension more closely. Being a new developer, shipping a new extension, and making significant code changes are on that list too. All four describe you on day one.

Then there's the Manifest V3 deadline pressure. MV2 support is already gone from mainstream Chrome — we covered what the Chrome 150 MV2 removal means for holdouts — and remote code execution (loading JavaScript from a server, eval() on fetched strings) is banned outright in MV3. Plenty of developers discover this from a rejection email rather than from the docs.

And one codebase does not mean one package. Firefox wants browser_specific_settings with an add-on ID, requires signing even for self-distribution, and its validator will flag things Chrome's tooling never mentions. Edge mostly accepts the Chrome flavor but runs its own certification against its own developer policies. The "write once" promise quietly becomes "package three times."

This is the point where a five-minute sanity check beats a five-day review queue. The free manifest generator builds and validates a cross-browser MV3 manifest with live store-policy checks, right in the browser, no sign-up — so the permission set that reaches the store has already survived a policy pass before you uploaded anything.

Gate two: what the review actually does

All three stores combine automated scanning with human review, but the mix and the pace differ.

Chrome Web Store. Google combines manual and automated review. Every submission goes through the same pipeline, whatever your tenure as a developer. Officially, "for most extensions, review is completed within a few days, but it can take up to a few weeks." If your item sits in pending review for more than three weeks, Google asks you to contact developer support. That tells you something about what "a few weeks" has become in practice.

The historical baseline has drifted. In early 2021, Google reported that most submissions finished review in under 24 hours, and over 90% within three days.

In 2026, a PSA thread on the chromium-extensions developer forum reports review times growing under submission volume. One developer there described a minor update stuck in review since April 2026. Previous versions of the same extension had been approved within a day.

Firefox AMO. Mozilla runs two distinct passes. First, an automated validator at upload time: errors block the submission outright, and Mozilla's own guidance warns that security and privacy warnings can fail review later. Then human review, for listed distribution.

Officially, signing and publishing can take up to 24 hours "or longer if your submission is selected for manual review." The community reading is blunter. On Mozilla's developer forum, the standard estimate for a manual review in 2026 is between one and two weeks. Backlog threads describe listed versions pending since November 2025. There's also a trap: AMO won't accept a new upload while an earlier version sits in the queue.

Microsoft Edge. Certification officially takes up to seven business days, for new submissions and updates alike. In Edge's own GitHub discussions, the developer support team puts typical review at five to seven business days.

A criteria-driven priority queue introduced in February 2025 accelerates only selected extensions. First-time submissions also sit behind developer account verification. Microsoft says that can take from a few days to a few weeks.

The honest summary table:

Store	Official guidance	Community-reported reality
Chrome Web Store	A few days, up to a few weeks; contact support after 3	Hours for trivial updates, 2–7 days typical for first submissions, weeks when flagged
Firefox (listed)	Up to 24 h unless selected for manual review	1–2 weeks for manual review; backlog cases 6+ weeks
Microsoft Edge	Up to 7 business days	~3 working days typical; 5–7 per support; account verification adds days

None of this is an SLA. Every number is "up to," and every clock includes weekends, queue depth, and the reviewer's judgment about whether your extension deserves a second look.

Gate three: rejection restarts everything

Here's the part tutorials skip: a rejection isn't a fine, it's a reset. You fix the problem, resubmit, and go to the back of the queue — and Google's documentation notes explicitly that review times may be longer after an extension has been rejected or warned.

Google's troubleshooting documentation maps what actually gets extensions rejected. The common reasons are almost embarrassingly preventable:

• Packaging errors. Files referenced in the manifest that aren't in the package — most commonly missing images — or wrong paths. The extension fails before a human forms an opinion about it.
• Functionality that doesn't match the listing. If your backend is down at the moment of review, or a promised feature actually just links out to an external service, that's a rejection under "functionality not working" and "minimum functionality."
• Single-purpose violations. An extension must have one narrow purpose. Bundling product reviews with ad injection, or a toolbar with five unrelated services, gets split-or-reject treatment.
• Clickbait metadata. Descriptions designed to attract attention rather than describe the extension.
• Missing privacy policy. If your product handles any user data, you must post an accurate, current privacy policy disclosing how data is collected, used, and shared — in the designated dashboard field — and transmit it securely. This one bites developers who genuinely collect nothing but wire up an analytics SDK that does.

On top of the official list, the community lore adds two classics: leftover files from an MV2 past (a stray background.html that MV3 service workers never use), and requesting permissions you don't need, which Google's support channels internally flag as a category of its own.

Every one of those is catchable before upload. That's exactly the job of a pre-publish scan: npx @extenshi/cli runs a security and policy scan from your terminal. It's 5 scans and 25 reads a month free, with prepaid credit packs past that if you ship often. Five minutes of scanning is cheap insurance against a week in the queue ending in a packaging error.

The onboarding gap

Approval is not adoption. This is the part where most developers declare victory and walk away — and then wonder why so few of those installs ever become active users.

The store listing got them to click install. Nothing in the store listing taught them what to do next. Nothing told them to pin the extension to the toolbar so they can actually find it. Nothing showed them the first action to take, the first workflow to try, the first moment where the extension proves it's worth the permission dialog they just clicked through.

That's the onboarding gap, and it's where the tools most developers never build are also the ones that matter most:

• A pin guide. A single illustrated page showing users how to find your extension icon and pin it to the toolbar, with your own icon embedded. It's the one onboarding step that almost nobody ships, and the one that correlates most strongly with day-1 retention. The pin guide generator builds this as a self-contained page you can host anywhere.
• Install instructions. Per-browser install steps — the store route for production users, the unpacked route for beta testers, what to try first. The install instructions tool ships this as markdown or a standalone page.
• A welcome page. The post-install page that opens automatically after someone installs your extension. It's your one shot at a first impression, and most developers leave it as the default empty page. The welcome page builder lets you compose one from illustration and text blocks, add click markers for key actions, and confirm that the install actually succeeded.
• Uninstall feedback. When someone removes your extension, Chrome lets you point setUninstallURL() at one page. Most developers point it at their homepage. The uninstall feedback tool gives you a branded survey with structured churn reasons and version trends, so you learn why you're losing users instead of guessing.

None of this is in the store review checklist. None of it affects whether you get approved. All of it affects whether the approval matters.

After approval: the loop nobody budgets for

Getting listed is not the finish line. It's the start of a maintenance loop:

• Every update re-enters review. Google is explicit that new items and updates to existing ones go through the same review process. Your hotfix for a production bug waits in the same queue as everyone's first submission.
• Three stores, three dashboards, three policies. The Chrome listing, the AMO listing, and the Partner Center submission are separate objects that drift apart unless you keep them in sync. The publish tool ships one artifact to all three stores via CLI or MCP, straight from your machine — one command instead of three dashboard sessions.
• Deadlines keep moving. The Chrome Web Store API V1 shuts down on October 15, 2026 — if your publish automation or analytics tooling still speaks V1, it stops speaking at all.
• Approval is not survival. The same tracker that counts quarterly launches found that of 124,342 extensions launched in the first half of 2026, only about 1.3% ever reached 1,000 users. The store listing is the beginning of distribution, not the end of it.

That last number is the one I'd pin above every desk. The gauntlet exists, it's worth walking through, and you should go in knowing that shipping is step one of a much longer job.

How long does it take to publish a Chrome extension, really?

Add up the realistic path for a first-time, three-store launch:

1. Icons, screenshots, promo tiles, and store copy: days to a week, depending on how many languages you're localizing into.
2. Privacy policy, data declaration, and homepage: hours if you have templates, days if you're writing from scratch.
3. Permission and manifest design, including the MV3 rework: days, if you've never done it.
4. Cross-browser packaging and testing: days.
5. Onboarding materials — pin guide, welcome page, install instructions: hours with the right tools, days without them.
6. First review round across three queues: 1–2 weeks typical, with real risk of more.
7. One rejection cycle, if it happens: add the full queue time again.

The pattern in every failure mode above is the same: the developer found out about the problem from the store, after the queue. Every tool worth using in this process exists to move that discovery earlier — before the upload, before the week of waiting, before the rejection email.

That's the design goal behind the full set of developer tools. The manifest generator catches permission and policy problems at design time. The privacy-policy generator turns your extension's real permissions into a GDPR/CWS/AMO-aligned policy instead of a blank page. The icon generator produces store-ready icon sets and promo tiles from a prompt. The SEO optimizer and AI visibility tool score your listing copy against competitors and AI assistants. The page generator builds a landing page. The pin guide, install instructions, welcome page, and uninstall feedback close the onboarding gap that turns installs into active users. The CLI scanner finds packaging, permission, and security rejection triggers before a reviewer does. The publish tool ships one artifact to all three stores from your terminal. When you claim your extension on the catalog, you also see it from the outside — the same view our scanners get.

The queue is real, and no tool removes it. But the difference between a two-week launch and a two-month launch is almost never the review itself. It's whether you entered the queue carrying a problem the queue was guaranteed to find — and whether you built the onboarding that turns an approval into a user base.