Every few months someone asks "how long does Chrome Web Store review take now?" and the answers range from "two hours" to "three weeks". Both are true, because review time is not one number — it depends on what changed in the package. I keep timestamps for every submission of my extensions, so here is the real spread.
The short version
| What you submitted | Observed time |
|---|---|
| Rejection (policy violation in the listing text) | ~10 minutes |
| Update, same permissions, small feature set | same day – 1 day |
| Update that adds a permission | several days |
| First submission of a new extension | days to weeks |
The pattern is boring and consistent: review time tracks the permission delta, not the amount of code.
The submissions I'm drawing from
Two extensions, both MV3, both already published:
-
CookieGuard — rejects cookie consent banners. Permissions:
storage+ host permission. -
AnkiMate — turns web pages into Anki cards. Permissions:
contextMenus,storage,sidePanel,scripting,tabs, host permission.
Neither runs remote code, and neither has widened its permission string since it was first approved. That last part matters more than anything else below.
Same-day approvals
CookieGuard 1.3.0 → 1.4.0. The change: the upgrade button stopped opening my website and started opening a Creem checkout URL, plus a yearly-plan link. Zero permission changes, a handful of new locale keys. Submitted on a Friday afternoon, live by the evening. The public listing page already showed the new version number a few hours later.
AnkiMate 1.3.0 → 1.4.0. Bigger in code — a fallback export path (TSV instead of AnkiConnect), a keyboard command (Alt+Shift+D), a trio of read-only AnkiConnect stats calls. Still the same permission string as 1.3.0. Submitted in the evening, live later that night.
CookieGuard 1.4.0 → 1.4.1. Per-site action overrides, a first-run welcome page, a reworked popup diagnostics line, and a rewritten store description submitted in the same pass. Approved within a day.
Three updates, three approvals, no extra review rounds. The only thing all three have in common: the permissions string did not change.
The ten-minute rejection
Earlier, on a different extension of mine, one submission came back in about ten minutes. It was not a code problem. The listing description listed competitor product names as a comparison — a trademark issue, not a functionality issue. The package was never inspected.
This is the failure mode people underrate: a policy rejection can arrive before a human ever looks at your extension, because listing text is checked mechanically. If you get a rejection in minutes, assume the description, not the code.
Why permission changes cost days
Chrome's review process escalates when the permission warning shown to users changes. The reviewer now has to judge whether the new capability is justified by what your description promises. That is a subjective call, so it goes into a slower queue.
Practical consequence: batch your permission changes. If you are going to add host access for one more API domain, ship it together with every other permission-adjacent change you have queued. Paying the slow review twice is the expensive mistake.
Corollary: if a release is genuinely permission-neutral, do not be afraid to ship it. Same-day approval is normal, not lucky.
Things that do not seem to affect review time
- Number of locales. I ship 9 languages on both extensions. English-only builds and 9-language builds both got approved the same day.
- Listing text changes bundled with a code update. One review covers both.
- Screenshots and icon changes. No visible effect.
- Description length, as long as it stays under the 16,000-character cap and does not read like keyword stuffing.
Things that do
- A permission string that changes. Even one added host.
- Remote code or remotely hosted logic. Anything that pulls executable instructions from your server is its own queue.
- A description that makes claims the package does not implement. This one is not just slow, it is the thing people get rejected for. If your store page lists a Pro feature, assume a reviewer can install the extension and check — which is why I now grep my own codebase for every feature name that appears in a listing before submitting.
- Touching the listing while a submission is in review. Wait. Editing mid-review can reset the state, and you lose the timestamp you were using to estimate.
How to actually measure this for yourself
Keep a small log: submission timestamp, permission diff (yes/no), what changed, approval timestamp. After four or five entries you will have a better estimate for your own extension than any blog post, including this one — review behaviour varies by category and by account history.
Two things I wish I had done from the start: write down the exact permission string of every released version (so "did this change?" is a diff, not a memory exercise), and diff the store description against the code before every submission.
The extensions in this log are CookieGuard and AnkiMate — both local-first, no telemetry, no account. I'm the developer, so treat the timings as one person's dataset, not an industry average.
Top comments (0)