Why Chrome Web Store rejects extensions — and how to fix each reason

1. Remotely hosted code

Under Manifest V3, the executable code that ships must be the code that was reviewed. Anything that fetches a remote payload and then executes it at runtime is treated as remotely hosted code. (Sandboxed pages and iframes that run remote content are handled separately by policy — the violation is your extension executing code it downloaded.)

Full guide: what counts as remote code, and what does not

What triggers it

• Injecting a <script> tag that loads JavaScript from an external URL (CDN, your server)
• Running a remotely fetched string as code with eval or new Function
• Dynamically importing a module from a remote URL
• Executing a server response as code

Fetching data (JSON) from a server is fine. The problem is turning what you fetched into executable code.

2. Over-broad host permissions

The most common rejection for functional extensions. If you request access to more sites than your feature needs, reviewers reject it as over-broad.

What triggers it

• <all_urls> or *://*/* when the feature only needs a handful of sites (broad access is allowed when it is genuinely required, but it draws a stricter, slower review)
• Domains left in the manifest that no feature actually uses

3. Unused or unjustified permissions

Reviewers reject extensions that declare permissions the code never actually uses, or sensitive permissions with no clear justification.

Full guide: how to word a permission justification

What triggers it

• A permission no feature depends on — often left over from an earlier version. (Judge it by feature, not by grepping for an API call: host, content-script and declarative permissions are used without a direct call.)
• Sensitive permissions like tabs, cookies, history, webRequest, or debugger without a matching feature

4. Privacy & data-use mismatch

An extension can be rejected — or removed after publishing — when the privacy declaration in the dashboard does not match what the code actually does with user data, or when a privacy policy is missing. The disclosure covers collection, use, storage and transfer — data that never leaves the browser still has to be declared.

Full guide: privacy policy requirements and the mismatches that cause rejections

What triggers it

• The listing says data never leaves the browser, but the code sends a license key, analytics, or telemetry
• Collecting data (history, cookies, page content) with no privacy policy URL registered
• The Data Use disclosures do not list every category the code collects, uses or stores — local-only handling included

5. Single purpose violation

Every extension must have one narrow, easy-to-understand purpose. A pile of unrelated permissions or features reads as multi-purpose and gets rejected.

6. Metadata & spam

Listing-level issues also cause rejections, even when the code is clean.

What triggers it

• Keyword-stuffed descriptions flagged as spam and placement
• Missing or low-quality icons and screenshots
• Misleading title or functionality claims

Pre-submit checklist

• Is any executable code loaded from outside the package?
• Are your host_permissions the domains you actually need — and is broad access justified if you kept it?
• Does every declared permission map to a feature you can point at?
• Does your Data Use declaration cover everything the code collects, stores and sends?
• Is the purpose single and obvious, with no unrelated permissions?
• Are the icons, screenshots, and description clean and accurate?

Rejection is not the end — it is a signal about what to change. Fix the item and resubmit; the resubmission gets a fresh review, and review times range from a few days to a few weeks.