Chrome Web Store rejection guide
How to check a Chrome Web Store rejection before resubmission
Use a local MV3 ZIP scan, official policy checks, and a manual review checklist to debug Chrome Web Store rejection risks before resubmitting.
Run local ZIP scanUse the scanner with this guide
Check the rejected ZIP before you resubmit
After reading the rejection email, upload the exact production ZIP you plan to resubmit. The scanner can point to package-level signals such as remote executable code, unsafe CSP, missing manifest references, broad permissions, and skipped-file limits.
Independent local static preflight only. This is not an official Chrome Web Store validation result.
Guide
What to check
Start with the submitted ZIP, then read the rejection email
This guide explains how to use the local scanner as one step in a rejection workflow. The scanner reads manifest.json, referenced files, extension pages, JavaScript files, CSP, permissions, icons, and privacy-review signals in the final production ZIP.
When to use it
Use it before uploading a new release, after switching to Manifest V3, after changing bundler output, or after receiving a vague Chrome Web Store rejection email that does not point to one exact file.
What it does not promise
This is not an official Chrome Web Store validator. It does not guarantee approval, detect malware, inspect Developer Dashboard fields, or verify runtime behavior that only happens after user interaction.
Use official docs as the final source of truth
The local scanner is a preflight aid. After it highlights package-level risks, compare each finding with Chrome's official troubleshooting, remote hosted code, packaging, privacy, and policy documentation before resubmitting.
Practical notes
How to apply this before resubmission
Use the rejection email as a lead, not as the whole diagnosis
A Chrome Web Store rejection email often points to a policy family, not to every file that needs to change. Treat the message as the starting clue, then inspect the exact ZIP that was reviewed. The scanner is useful because it reads the packaged manifest, generated HTML, worker files, bundled JavaScript, declared pages, CSP strings, and permission declarations together. That package-level view can reveal build output that is not obvious in your source folder.
- •Keep the rejection email open while scanning the ZIP.
- •Fix High findings before editing listing copy or screenshots.
- •Rebuild and rescan the release ZIP after each packaging or bundling change.
Separate package findings from store-listing review work
The scanner can flag static package signals, but it cannot inspect Developer Dashboard text, reviewer notes, privacy-practice form answers, screenshots, or runtime behavior after user interaction. Keep two queues: package fixes that can be verified by rescanning the ZIP, and store-listing fixes that must be reviewed manually in Chrome Web Store Developer Dashboard.
- •Package queue: RHC, CSP, missing files, manifest references, broad permissions.
- •Listing queue: purpose statement, privacy fields, screenshots, support URLs, reviewer notes.
- •Do not resubmit until the package queue and dashboard queue are both reviewed.
Turn the rejection notice into a package-level checklist
A Chrome Web Store rejection notice usually names a policy area, not every exact file that caused the reviewer concern. Treat the notice as the starting point, then inspect the package that was uploaded. The scanner is designed around that workflow: it reads the release ZIP, checks manifest references, scans extension-side text files, and separates code findings from scan-limit notes so you can decide what needs a code fix and what needs manual review.
- •Start with the violation name and match it to the relevant guide page.
- •Scan the same ZIP you intend to upload, not an unpacked development folder.
- •Use High findings for code changes and Medium/Low findings for reviewer-note preparation.
What to include in a resubmission note
After you fix the package, your reviewer note should be short and evidence-based. Do not paste a long policy essay. State which packaged files changed, what remote or dynamic execution pattern was removed, and whether you updated privacy or permission explanations in the dashboard. If the scan report still contains Medium manual-review items, explain why they are data requests, local assets, or intentional permissions rather than executable remote code.
- •Mention the package version and the main files changed.
- •Describe replacements in operational terms, such as bundled local script or removed eval path.
- •Avoid promising that a static scan proves approval; use it as supporting evidence only.
Why the final ZIP matters more than source intent
Many rejection investigations become confusing because the source repository looks clean while the compiled output contains injected loaders, analytics snippets, generated workers, copied CDN examples, source-map comments, or missing referenced files. Chrome Web Store review is based on the submitted package. The scanner follows that practical boundary by analyzing the packaged artifact and showing scan limits separately from code findings.
- •Check generated HTML, service worker output, content script bundles, and copied vendor files.
- •Remove stale build artifacts before zipping the release.
- •If a finding comes from a comment or source map, treat it as manual review and decide whether to remove it from the shipped package.
Checklist
Action checklist
- □ Build the same ZIP that you plan to submit to Chrome Web Store.
- □ Confirm manifest.json is at the ZIP root, not inside a nested project folder.
- □ Run the local scanner and fix High findings before reviewing Medium and Low notes.
- □ Rebuild the production ZIP after each fix and scan the rebuilt package again.
- □ Review Chrome Web Store listing copy, privacy disclosures, screenshots, and reviewer notes separately.
Examples
Common cases this page helps with
Remote script in an extension page
A popup.html file loads a script from a CDN. The scanner flags the remote script because executable code should be bundled into the extension package.
Nested manifest packaging mistake
The ZIP contains my-extension/manifest.json instead of manifest.json at the root. The scanner reports this as a High packaging risk.
Broad host permissions
A manifest requests <all_urls>. The scanner asks you to verify whether narrower host patterns or optional permissions can support the same single purpose.
FAQ
Frequently asked questions
Is this an official Chrome Web Store validator?
No. It is an independent local static preflight checker for common package-level rejection risks. Chrome Web Store review can include additional policy, metadata, privacy, and behavior checks.
Should I scan source code or the release ZIP?
Scan the release ZIP. Chrome Web Store reviews the submitted package, so bundler output and packaging mistakes matter.
Does the scanner upload extension files?
No. The ZIP is read in the browser. Do not add analytics that sends file paths, snippets, manifest content, or source code.
Official sources
Sources used for this page
These links are listed so scanner findings and page guidance can be checked against Chrome's source documentation. This site remains an independent preflight tool.
Chrome Web Store: Troubleshooting violations
Explains how Chrome Web Store rejection and violation references should be interpreted and fixed.
Chrome Web Store: Prepare your extension
States that the Chrome Web Store upload ZIP should contain manifest.json at the root, not nested inside a folder.
Chrome Extensions: Deal with remote hosted code violations
Defines remotely hosted code as browser-executed JS/WASM loaded outside the extension package and recommends scanning compiled submission output for http/https references.
Chrome Web Store: Fill out the privacy fields
Explains the Developer Dashboard privacy practices tab, single purpose, and permission justification fields.
Chrome Web Store Developer Program Policies
Sets the broader user trust, transparency, and user data handling policy baseline for Chrome Web Store items.
Chrome Web Store: Update your item
Explains that code, manifest, or packaged asset changes require uploading a new ZIP and incrementing the version number.
Related guides