What does Purple Potassium mean?

It is the Chrome Web Store notification ID for the excessive permissions violation: your extension requests a permission it does not use, or a permission broader than the feature actually needs.

Do I have to remove every flagged permission?

No — remove the ones you don't use, narrow the ones that are broader than needed, and keep the ones your features genuinely require. A permission you keep should have a one-line justification in your listing's privacy practices.

Will fixing permissions guarantee approval?

No one can guarantee approval — the decision is Google's. Fixing the flagged permissions addresses this specific violation; other policies are reviewed separately.

Purple Potassium: fixing the Chrome Web Store "excessive permissions" rejection

Purple Potassium is the notification ID Google attaches to the excessive permissions violation. The stated intent of the policy is to prevent excessive and unnecessary access to user data by extensions. In practice, two different situations trigger it:

A permission you declare but never use. It sits in the manifest; no code path calls the API that needs it.
A permission broader than the feature requires. The feature is real, but a narrower permission would implement it — the classic case is a broad host permission where specific origins would do.

Google's stated reasons

The extension is requesting a permission but not using it.
The extension is requesting a permission that is not required to implement the functionality the extension provides.

Audit your manifest in ten minutes

Go through permissions, optional_permissions, and host_permissions one entry at a time and answer: which line of my code needs this?

grep -rn "chrome.storage"  src/   # justifies "storage"
grep -rn "chrome.cookies"  src/   # justifies "cookies"
grep -rn "chrome.alarms"   src/   # justifies "alarms"

Note the special case: most chrome.tabs calls work without the "tabs" permission — it is only needed to read sensitive tab properties like url, title, or favIconUrl. If you never read those, drop it.

A grep pass is a first filter, not proof: check wrappers, manifest-declared content scripts, and fetch-based flows before deleting anything — and re-test after every removal.

Common swaps reviewers want to see

Broad: "host_permissions": ["<all_urls>"] when your extension only works on two sites.

Narrow: "host_permissions": ["https://chatgpt.com/*", "https://claude.ai/*"]

Broad: a standing host permission just to act on the page where the user clicks your icon.

Narrow: "activeTab" — temporary access to the current tab, granted at the moment of the user's gesture. (Different job from "tabs", which is about reading sensitive tab metadata like URLs and titles.)

Leftover: "alarms", "cookies", or "webRequest" from a feature you removed months ago.

Fix: delete it. Unused entries are the easiest version of this rejection to earn.

Before you resubmit

Remove or narrow the flagged permissions and bump the version number.
For every permission you keep, write a one-line justification in the developer dashboard's privacy practices section — one honest sentence about which feature uses it.
Re-test the extension: removing a permission your code silently relied on is the most common way a "fix" breaks the build.

Check yourself before Google does. Paste your manifest.json into the free manifest preflight checker, or decode your full rejection email with the rejection decoder.

Want a second pair of eyes? Use the free triage form — we'll say which permissions are likely drawing scrutiny. It is our reading, not a ruling from Google, and nobody can guarantee approval.