How to write permission justifications

One of the most common rejection reasons — and how to word it so a reviewer can follow you.

Most extensions are not rejected because a permission is wrong. They are rejected because the justification field describes the code instead of the user benefit. Reviewers are checking one thing: can a user understand why this extension needs this access?

The pattern behind almost every rejection

Too vague: "Needed for the extension to work properly."
Too vague: "We use chrome.storage to store data."
Clearer: "Saves the user's export format preference so they do not have to reselect it on every use. Nothing is sent off the device."

The difference is not length. It is that the third one names what the user gets and what does not happen to their data.

Wording per permission

storage

Stores the user's settings (selected theme and export format) locally so the extension remembers them between sessions. No user content is stored and nothing leaves the browser.

activeTab

Reads the current page only after the user clicks the extension icon, so the extension can extract the article text the user asked to save. Access ends when the tab is closed.

scripting

Injects a small script into the page the user is on when they press the toolbar button, to highlight the matched elements. The script is not injected automatically on any site.

downloads

Saves the file the user generated in the extension to their Downloads folder when they press Save. The extension never starts a download without a user action.

tabs

Reads the titles and URLs of open tabs so the user can pick which tabs to include in the session they are saving. Tab data is used only while the popup is open and is not transmitted.

If you only need the URL of the tab the user is acting on, use activeTab instead. Requesting tabs when activeTab would do is a common thing reviewers push back on.

Host permissions

Too vague: <all_urls> with "the extension needs to work on any site."
Clearer: "The extension reads chat content on chatgpt.com and claude.ai so the user can export their own conversations. Those two hosts are the only ones listed."

Broad host permissions have a better chance when the breadth is genuinely required and the justification explains why a narrower set cannot work. If you can list the hosts, list them.

Four rules that cover most cases

  1. Say what the user gets, not what the API does.
  2. Name the user action that triggers the access ("after the user clicks…").
  3. State what does not happen — no transmission, no storage of page content, no background collection. Only if true.
  4. Match your privacy policy. A justification that claims nothing is transmitted while the policy mentions analytics is one of the fastest ways to get sent back.

Before you resubmit

Reviewers re-evaluate the whole manifest on a resubmission, not only what changed. An unchanged permission can be flagged on a later submission, so review every entry, not just the one that was called out.

Check your manifest first. The free manifest checker lists every permission you declare, flags the ones reviewers question most, and tells you which ones need a justification. No signup. Your manifest is read in your browser and is not uploaded; the page itself keeps an anonymous view count.

Need the full checklist, justification templates for every permission, and a privacy policy template you can adapt? The Chrome Web Store Submission Kit (paid, opens in a new tab) covers the whole submission, not just permissions.

More: After a rejection: what to change · Privacy policy requirements · What counts as remote code · More: How long Chrome Web Store review takes · Privacy policy generator · Start here
PC Wise AI