How long does Chrome Web Store review take? The process and timing

How long does Chrome Web Store review take, by case

Google doesn't publish exact hours. In its review docs it does publish is a range and a list of things that stretch it. Here's that turned into a planning table. Once you're through, Chrome Web Store SEO decides who finds you.

The "slow end" means a few weeks. If you're already waiting, see what to do while it's pending. Never promise a launch date that needs a fast review.

Ways to keep it short

• Trim permissions to what each feature needs.
• Keep code readable. Google's policies say extension logic must be easy to work out from the submitted code. The table above lists every trigger Google names.
• Ship smaller updates more often instead of one huge one.
• Use deferred publishing so review can finish before your launch day.

Submit a week before you need it live, then publish on the day.

The Tools category page lists the same extensions with users and ratings.

The Chrome Web Store review process in five steps

Timing makes more sense once you know what happens in the queue. Google's own docs describe the flow, and it looks like this.

1. You upload a packagein the developer dashboard and fill in the listing, privacy fields and permission justifications.
2. You submit itThe item shows as pending review. Our page on what to do while it's pending covers the wait.
3. Google checks the code and listingagainst its program policies.
4. You get a verdict by emailApproved, or rejected with the policy it broke.
5. It publishes, straight away or when you click publish if you turned on deferred publishing.

Updates go through the same review as a new item. A one-line fix can still wait in the queue.

What review checks, in plain words

Reviewers aren't grading your design. They're asking whether the extension does what the listing says and nothing it shouldn't.

The single purpose rule trips up a lot of first-time builders. A tab manager that also changes your new tab page and blocks ads is three products in one box. Split them, or cut the extras.

How common big permissions are

Broad access is one of the named reasons for a longer review. It's also common. In our crawl observed 3 Oct 2026, 11,272 of 65,655 extensions with store data asked for access to all sites.

activeTab is the quiet win here. It gives access to the current tab only after the user clicks, which is often all a tool needs. Swapping all-sites access for it can shorten review and makes the install prompt less scary.

If you get rejected

The email names the policy. Your live listing stays as it was.

1. Read the named policy in full, not just the email summary.
2. Fix that one issue. Don't bundle new features into the resubmission.
3. Rewrite the justification field so each permission names the feature that uses it.
4. Resubmit, or use the Appeal button in the dashboard if you think the call was wrong.

Google says support usually replies to appeals within three days. Keep your note short: what the policy says, what your code does, and where in the package a reviewer can see it.

How often extensions ship updates

Every update is a new trip through review, so the update rhythm of a niche tells you how often rivals accept that wait. Here's how the whole store looked on 3 Oct 2026.

About one in three listings had an update in the past month. Another third hadn't shipped in over a year. Review time clearly doesn't stop active teams from shipping often, as long as each update is small.

A pre-submit checklist

Most slow reviews start with something you could have caught before clicking submit. Run through this list each time.

• Every permission has a feature. Write them as pairs. Delete any permission with no feature next to it.
• Host access is as narrow as it can be. List the sites by name if your tool only works on a few.
• No remote code. Everything the extension runs ships in the package.
• Readable build output. Bundling is fine. Obfuscation isn't.
• Privacy fields match the code. If you collect anything, say what and why.
• Screenshots show the real tool, at the size the store expects.
• The summary names one job.

Tick all seven and you've removed the triggers you control. The rest is queue time.

Planning launch dates around review

Since nobody outside Google knows the exact wait, plan with a buffer you can live with. Here's a simple way to set a date.

Use deferred publishing for anything with a fixed date. You get the approval early and choose the moment it goes live. The New launches page shows how many young listings went live in the past 90 days, so you can see how crowded launch weeks get.

For a first extension

A first submission feels like the slowest, partly because everything is new and partly because Google gives new accounts a closer look. Our guide to setting up a developer account covers the steps before this one.

Keep the first version small. One job, few permissions, a clean listing. You can add features in later updates once you have a track record. That also gives you a reason to ship regular updates, which keeps the listing looking cared for.

Why you can't see this from the store

Outside the dashboard, nobody can see a pending review. What anyone can see is the version change once it's live.

We're biased, as the makers of Ext Watch. Our tracker records the date we first see each new version, which tells you when a rival's update landed. It can't tell you how long they waited for it.

Fill the kettle less, and it boils sooner.