Jenny Wilson 
You spend weeks building your browser extension. You write the code, test it, package it, and submit it to the Chrome Web Store — only to get a rejection email three days later. It is one of the most demoralizing moments in extension development, and it happens to experienced developers constantly.
The good news: most rejections are avoidable. The bad news: Google’s rejection emails are often vague enough that developers fix the wrong thing and re-submit only to get rejected again.
Here are the most common reasons extensions get rejected, and what you can do about each one.
1. Overly Broad Host Permissions
The most frequent rejection reason. Requesting <all_urls> or https://*/* in your manifest when your extension only needs to run on specific domains will almost always trigger a rejection — or at minimum a “single purpose” policy violation flag.
The fix: Request only the specific hosts your extension actually needs. If your content script only runs on https://github.com, request only https://github.com/*. Use the activeTab permission for cases where you need temporary access to the current tab.
If you genuinely need broad permissions (for a productivity tool that works on any site, for example), they must be declared as optional permissions and requested at runtime with user consent. Chrome’s policy requires broad host permissions to be optional unless the extension’s core functionality is impossible without them.
2. Privileged Permissions Without Justification
Permissions like history, bookmarks, tabs, cookies, and management are considered privileged and scrutinized heavily. If your extension requests history but the reviewer cannot identify a clear reason in the description or functionality, it gets flagged.
The fix: Audit your permission list. Remove anything your extension does not actively use. Write a clear justification for each permission in your store listing description. If a permission is only needed for a secondary feature, make it optional.
LightningAddon ships with a manifest permission linter that runs in CI. It enforces the rule that privileged permissions must be declared as optional — catching this class of problem before your first submission, not after your third rejection.
3. Deceptive or Misleading Store Listing
Your screenshots, description, and name all have to accurately reflect what the extension does. Reviewers flag anything that looks like it overstates functionality, uses competitor brand names, or implies official affiliation with a product or service.
The fix: Write a clear, specific, honest description of what your extension does. Use screenshots that show real functionality in the extension UI, not marketing mockups. Avoid phrases like “the best” or “official” unless they are literally true.
4. Remotely Hosted Code
Chrome MV3 does not allow extensions to fetch and execute remote JavaScript. If your extension loads scripts from an external URL using eval, new Function, or dynamic <script> injection from a remote source, it will be rejected.
The fix: All executable code must be bundled with the extension package. This is one of the reasons LightningAddon uses Vite as the build system — every dependency is bundled at build time with zero runtime code fetching.
5. Missing or Incorrect Privacy Policy
Any extension that handles user data — even just browser history, cookies, or any personal information — is required to link to a privacy policy. Many developers forget this, and the review team catches it.
The fix: Add a privacy policy URL to your store listing. It does not need to be a lawyer-written document, but it does need to exist and be accessible at a public URL. Describe what data you collect, how you store it, and whether you share it.
6. Extension Does Not Work as Described
Reviewers actually test extensions. If your description says the extension does X but the reviewer cannot get X to work, it gets rejected. This happens more often than you would expect — especially with auth flows that require an account or features that only activate on specific pages.
The fix: Test your submission thoroughly on a clean Chrome profile. Include testing instructions in the developer notes during submission if your extension requires an account or specific setup steps. The reviewer needs to be able to verify your functionality quickly.
Catching These Problems Early
Most of these issues are detectable before submission with the right tooling. LightningAddon’s manifest permission linter runs on every CI build and enforces the permission policy rules that Chrome reviewers check manually. It will not catch every edge case — but it eliminates the most common rejection causes before you ever click “Submit.”
The rest comes down to discipline: request only what you need, describe only what you do, and test what you ship.
