Skip to main content
A Chrome Web Store rejection isn’t a dead end — it’s a list of specific things to fix before resubmitting. Google’s rejection emails always cite a policy and often hint at what needs to change. Use this guide to match the rejection reason you received to a concrete fix.

​
Reading the rejection email

Every rejection email includes:
  • The policy that was violated (for example, “Permissions” or “Misleading Metadata”)
  • A link to the relevant policy documentation
  • Sometimes, a specific description of what triggered the review
Read the email carefully before making changes. Resubmitting without addressing the cited issue will result in an immediate second rejection.

​
Common rejection reasons

Cause: Your extension requests a sensitive permission — such as cookies, storage, or access to user data — but you didn’t link a privacy policy in the Developer Console.Fix: Create a privacy policy that explains what data your extension accesses and how it’s used. Host it on a public URL (your own website or a free policy generator). Then open the Chrome Web Store Developer Console, go to your extension’s listing, open the Privacy tab, and paste the URL.
Cause: Your manifest.json requests permissions that your extension’s code never actually uses, or it requests broad permissions (like <all_urls>) when a narrower scope would work.Fix: Remove every permission that isn’t actively used. Use activeTab instead of tabs where possible. Use specific host patterns (for example, https://*.example.com/*) instead of <all_urls>.
Cause: Your extension’s name or store description doesn’t accurately reflect what it does, uses trademarked brand names in a misleading way, or omits significant behavior (such as changing the user’s search engine or homepage).Fix: Rewrite the store description to lead with the primary feature in plain language. If your extension modifies browser defaults, state that explicitly in the first sentence. Use a descriptive name that reflects functionality (for example, “Price Highlighter for Amazon”) rather than a vague or brand-adjacent name.
Cause: Your store listing is missing screenshots, or the screenshots don’t clearly show the extension’s functionality in use.Fix: Add at least two screenshots (1280×800 or 640×400 pixels) that show your extension actively running on a real webpage. Avoid screenshots of just the icon or a blank popup. Captions that explain what the screenshot shows are helpful but not required.
Cause: In the Developer Console, you provided a vague reason for a sensitive permission (for example, “needed for functionality”).Fix: Be specific for every permission that requires justification. Explain exactly what the permission is used for and why it’s necessary.
“The storage permission is used to save the user’s selected highlight color so it persists across browser sessions.”
Cause: Your extension uses eval(), Function(), or fetches JavaScript from a remote server at runtime.Fix: Manifest V3 prohibits all forms of remote code execution. All logic must be bundled inside the ZIP you upload to the store. Remove any eval() calls and any fetch calls that retrieve and execute scripts.
Cause: Your extension is too similar to an existing item in the store, or it doesn’t offer meaningful new functionality compared to existing tools.Fix: Add a distinguishing feature or a clearly different user experience. Describe what makes your extension unique in the store listing. Avoid submitting minor reskins of popular extensions without adding real value.
Cause: The extension does something the user didn’t explicitly agree to — such as modifying the new tab page, changing the default search engine, or injecting content into pages not covered in the description.Fix: Every behavior that affects the user’s browser experience must be described in the store listing. If your extension changes browser defaults, those changes must require explicit user opt-in and be clearly documented.
Cause: You submitted an extension with no functional features, a “coming soon” message, or stub code.Fix: Complete the extension’s core functionality before submitting. Google will not approve an extension that doesn’t do what its listing describes.
Before resubmitting after any rejection, increment the version field in your manifest.json (for example, from "1.0.0" to "1.0.1"). The Chrome Web Store will not accept a new submission with the same version number as a previous one.

​
Appealing a rejection

If you believe the rejection was a mistake, reply directly to the rejection email. Be polite, reference the specific policy Google cited, and explain clearly how your extension complies with it. Include any supporting evidence (screenshots, code snippets) that demonstrates compliance.
Do not resubmit the same unchanged ZIP after a rejection. Google’s review system will detect the duplicate and reject it immediately. In repeated cases, this can result in a developer account suspension.