A new Chrome Web Store account can publish two extensions

This is not in the part of the documentation you read while building an extension. You meet it the first time you press Submit on your third one — or, worse, while planning a roadmap that quietly assumed the number was unbounded. Here is the shape of the limit, when it bites, and what happened when we asked for more.

7 September 2026

A newly registered Chrome Web Store developer account starts with a publishing limit of two items. The part that catches people is the accounting: the slot is consumed when you submit, not when Google approves. We watched this on our own dashboard on 30 August 2026 — our first extension was still showing Pending review and the counter already read 1.

Two consequences follow immediately, and both are about planning rather than code:

• You cannot submit a placeholder to "reserve the name" and clean it up later. That placeholder is one of your two.
• A rejected-and-resubmitted item does not multiply, but a second product you were not sure about does. If you have two ideas and one account, the second submission is a decision, not an experiment.

There is a way to ask for more, and looking for it early is a waste of an afternoon: the control appears in the Developer Dashboard only once the account is actually at its limit. Before that there is nothing to click, which reads like the feature does not exist. So the sequence is fixed — publish two, then ask.

When you do ask, the refusal comes back as one of two reasons, and they are not interchangeable. One is about your extensions: the account needs higher sustained engagement, meaning installs and continued weekly use of what you already shipped. The other is about your account: its tenure and activity — how long it has existed and how consistently you have been present in it.

Reading which one you got is the whole value of the reply, because the two point at completely different work. The first is a growth problem. The second is a calendar problem, and no amount of shipping fixes it this week.

We asked on 6 September 2026, from an account created on 30 August 2026 — seven days old. The answer was the second reason: the publisher account did not meet the tenure-and-activity requirement, and we could apply again later. Nothing about our extensions' usage was mentioned.

That is a useful data point precisely because it is boring: with a one-week-old account you can stop trying to game the engagement side, because engagement was not what was being measured. Google does not publish the threshold — not a day count, not an install count — and we are not going to invent one. What we can say is what a seven-day account got told, and on what date.

What we changed as a result: reapply monthly rather than repeatedly, keep both extensions genuinely updated instead of pushing empty version bumps to look active, and answer the support page. "Activity" that consists of releases with nothing in them is a worse bet than waiting, because it costs review cycles and users notice.

The obvious workaround is a second developer account. We ruled it out and it is worth saying why out loud, because the reasoning generalises past this limit.

First, circumventing a limit through additional accounts is the kind of thing store policies exist to catch, and the penalty is applied to the accounts — including the one with your live extension on it. Second, and more quietly dangerous: for most small publishers the Google account behind the developer account is also the recovery path for their code host, their DNS and their domains. Putting it at risk to gain one listing slot trades a compounding asset for a rounding error.

The cheaper answer is that other stores do not spend Chrome's slots. Microsoft Edge Add-ons takes the same MV3 zip and has its own quota; registration there had no fee when we checked on 30 August 2026, though verification of a company account is described as taking days to weeks and the account type cannot be changed afterwards, so it is worth starting that clock before you need it. Firefox is a genuine port rather than a re-upload — an MV3 extension built on background.service_worker needs work before AMO will take it.

The limit is less a wall than a forcing function: it makes you finish two things instead of starting five. Rank your ideas before you submit rather than after, treat the second slot as the expensive one, and start the queue at another store early since that part is waiting, not work.

Both of our slots are spent. As of 7 September 2026 one extension is published and a second is submitted and in review — that is 2 of 2, which is exactly how we ended up reading the refusal notice closely enough to write this. The one in review reads a page aloud and highlights each sentence as it goes; what it does, and what it will cost is a pre-order page that says plainly what exists today and what does not.