How long does Chrome Web Store review take?

There is no published guaranteed turnaround. Simple updates can clear quickly while first submissions with sensitive permissions can take considerably longer, so plan launches with slack rather than a fixed date.

Does resubmitting speed up a pending review?

No. Uploading a new package replaces the pending one and the review starts over on the new package. Leave a pending submission alone unless the change is important enough to justify restarting.

What makes a review take longer?

Broad host access, sensitive permissions such as history, cookies, downloads or debugger, user-data handling that has to be checked against the declarations, unreadable bundles, and first submissions from new developer accounts.

What should I do while waiting?

Re-read the manifest as a reviewer would, confirm the privacy policy URL is public and about this extension, check the listing copy against what the code does, and prepare the next version locally without uploading it.

Chrome Web Store Review Stuck: Why It Takes So Long and What To Do

Expectations

1. What counts as a normal wait

Google does not publish a guaranteed turnaround, and reported waits range from under a day to several weeks. The practical stance is to plan launches with slack rather than a fixed date, and to avoid announcing a release day that depends on a review completing.

A long wait on its own is not evidence of a problem. What is worth checking is whether your submission contains the things that tend to invite a closer look.

Causes

2. What tends to draw extra scrutiny

Broad host access. <all_urls> or wide match patterns are allowed when genuinely needed, but they invite closer scrutiny — and a longer review.
Sensitive permissions. Anything touching browsing history, cookies, downloads, or the debugger raises the bar for justification.
Data handling. Extensions that collect, store, or transmit user data get their declarations compared against the code.
Obfuscated bundles. Minified vendor code is fine; code deliberately made unreadable is a policy problem in its own right and can end in rejection rather than a slow approval.

What helps: Ship the narrowest permission set the feature needs, write the justification fields as if the reviewer has never seen your product, and make the data declarations match the code exactly. None of this guarantees speed — it removes the reasons a review would stall.

Careful

3. Resubmitting resets the queue

A self-inflicted delay worth avoiding is uploading a new package while the previous one is still pending: the new submission replaces the pending one and the review runs against the new package. Depending on what you change, editing a pending item may also send it back through review.

Fix: Once a submission is in review, leave it alone unless you have a reason strong enough to justify starting over — for example a security fix. Queue your other changes locally and ship them in the next version.

Meanwhile

4. What to do while you wait

Re-read your own manifest as a reviewer would: does every permission map to a feature you can point at?
Check that the privacy policy URL is public and describes this extension.
Confirm the listing copy does not claim anything the code cannot support.
Prepare the next version locally, but do not upload it.
If the wait becomes unusually long for your case, the developer support channel is the correct route — not a resubmission.

Doing this work now means that if a rejection does arrive, you are more likely to be fixing one specific item than starting an audit from zero.

Next step

5. If it comes back rejected instead

A rejection names a policy area. Often the fix is narrower than the wording suggests — a permission to remove, a declaration to correct, a description to rewrite — though some rejections do require real changes to what the code does. The companion guides walk through each common reason and what to change:

Been waiting longer than feels normal?

Paste your manifest.json — or the rejection email if one arrived. We read it and tell you which parts are likely drawing the extra scrutiny and what we would change. Free, no signup, and it is our reading rather than a ruling from Google.

Prefer to fix it yourself?

The Chrome Web Store Submission Kit is the working document we use on client submissions: permission justification lines you adapt per permission, a Data Use worksheet that maps code paths to declared categories, a privacy policy template, listing-copy rules, and a rejection decoder that turns the email wording into a concrete change. 6-page PDF, one-time $19.

Get the kit — $19