Google's documentation says several things trigger an in-depth Chrome Web Store review: a new developer or extension, dangerous permission requests, significant code changes, broad host permissions or sensitive execution permissions, and large or hard to review code. Most reviews finish within a few days but can take up to a few weeks.
Why this matters to buyers and publishers
If you publish extensions, knowing the triggers helps you plan release timing. If you buy or approve extensions for a company, the same list is a free risk signal. Whatever slows a reviewer down is also what deserves your attention during an internal approval.
The review process page also notes that reviewers check each requested permission is necessary and used appropriately. Obfuscated code is disallowed. Minified code is allowed but harder to review.
The triggers in plain words
| Trigger | What it means in practice | Reducing the delay |
|---|---|---|
| New developer or new extension | No track record with the store | Complete the account profile, ship a small first version |
| Dangerous permissions | Access that can read or change sensitive data | Ask only for what a feature needs |
| Significant code changes | A big diff between versions | Split risky changes from routine ones |
| Broad host permissions | Patterns such as all URLs, or sensitive execution permissions | Narrow the match patterns, or use optional permissions |
| Large or hard to review code | Bundles reviewers cannot follow | Ship readable code, avoid obfuscation |
How long to expect
The documentation says most reviews complete within a few days and may take up to a few weeks, and that reviews can run longer after a rejection or warning. If a submission has been pending for more than three weeks, it tells developers to contact developer support. Plan any security fix release with that range in mind, and do not rely on a same day approval.
Outcomes you should know
- Approval: no violation found.
- Rejection: the developer is emailed the violated policy and appeal guidance. The existing listing is unchanged and end users are not notified.
- Warning: for a minor violation on a published item. The developer typically has 7 to 30 days to submit a fixed version, or the item is taken down.
- Takedown: the item is removed from the store and search. If it stays unresolved for several weeks, Chrome disables the extension for users, who can re-enable it.
- Malware and extreme violations: removal without notifying the publisher, a possible permanent account suspension, and users cannot re-enable the extension.
What a company can borrow from this
Use the same triggers as an intake screen. Before approving an extension for employees, ask whether it has broad host access, whether code is readable, whether the publisher is new, and whether a recent update changed permissions. Anything that would have drawn extra scrutiny from the store deserves a closer look from you. Store approval is a minimum, not a verdict.
Reviews are also not one time. The documentation says published items are reviewed periodically and when triggered by reports or by a new submission violation, so an extension that was fine last year can still be actioned later. Keep your own inventory current rather than assuming a past approval still holds.
Safeguard's asset discovery and dependency scanning can feed the software side of that intake record.
Quick check
Does a rejection tell users the extension had a problem?
No. The documentation says the listing is unchanged and end users are not notified when a submission is rejected.
Is minified code banned?
No. Obfuscated code is disallowed. Minified code is allowed but harder to review.
What if my review is stuck?
Google says to contact developer support if an extension has been pending for more than three weeks.
Sources
Last reviewed: 19 October 2026.
