Chrome Extension Permissions Explained (and How to Justify Them)
Chrome extension permissions are declarations in manifest.json that tell the browser (and the user) what your extension can access. Chrome uses them to show an install-time warning listing what the extension can do. Pick more than you need and users get scared off. Pick too few and your extension won't work.
The Chrome Web Store review team also looks at your permissions. Broad permissions without a clear justification are one of the most common reasons extensions get rejected or flagged.
The two types of permissions
API permissions give your extension access to Chrome's built-in APIs. You declare them in the "permissions" field.
Host permissions give your extension access to specific websites, meaning it can read and modify page content, intercept requests, or inject scripts on those URLs. You declare them in "host_permissions".
Common API permissions
activeTab
Grants temporary access to the current tab when the user explicitly invokes the extension (by clicking its toolbar button or using a keyboard shortcut). The access lasts only for that interaction.
Use this when your extension only needs to act on the page the user is currently looking at. It avoids a persistent host permission, which means no scary warning at install time.
storage
Lets your extension read and write to chrome.storage.local and chrome.storage.sync. Use it to save user preferences, persist state between sessions, or sync settings across devices.
Almost every extension needs this. It's low-risk and Chrome's warning for it is minimal.
scripting
Allows programmatic injection of JavaScript or CSS into pages via chrome.scripting.executeScript() and chrome.scripting.insertCSS(). Required in MV3 if you want to inject code on demand (as opposed to declaring static content scripts in the manifest).
You still need a host permission or activeTab for the injection to actually work.
tabs
Gives access to metadata about open tabs: URL, title, favicon, tab ID, window ID. It does not grant access to page content.
A common mistake: requesting tabs permission when you only need the current tab's URL during an activeTab interaction. In that case, you can read tab.url from the callback without needing the tabs permission at all.
notifications
Lets the extension show system-level desktop notifications. Needs a user gesture or background event to trigger. Chrome will show a one-time prompt asking the user to allow notifications from the extension.
contextMenus
Adds items to the right-click context menu. Requires no scary warnings and is easy to justify. Useful for "send to extension" type features.
Host permissions
Host permissions let your extension access specific websites. The format is a URL pattern, and the most common ones are:
- "https://example.com/*": access only to one domain
- "https:///": access to all HTTPS sites
- "<all_urls>": access to every URL, including HTTP and local files
"<all_urls>" and "https:///" both trigger Chrome's most alarming install warning: "Read and change all your data on all websites." That warning correlates with lower install conversion and more careful review scrutiny.
Least-privilege: use the narrowest permission that works
If your extension only runs on GitHub, declare "https://github.com/*". If it only runs on sites the user explicitly activates it on, use activeTab and no host permission at all. Reserve "<all_urls>" for extensions that genuinely need to operate across every site the user visits, like password managers or adblockers.
How broad permissions slow down review
The Chrome Web Store team applies more scrutiny to extensions with sensitive permissions. Extensions requesting "<all_urls>", tabs, webNavigation, or declarativeNetRequest with many rules are reviewed more carefully. This is reasonable: those permissions have more potential for misuse.
Expect a longer review window (sometimes several weeks) and a higher chance of being asked to justify the permission in writing before your extension is approved.
Justifying permissions in your submission
When submitting to the Chrome Web Store, you fill out a "single purpose" description and may be asked to explain why each permission is needed. Be specific:
- Bad: "We need host permissions to enhance your browsing."
- Good: "We inject a price-comparison widget on Amazon product pages, which requires host access to amazon.com."
If you can't write a one-sentence justification for a permission, you probably don't need it.
Extension Coder generates extensions with only the permissions your described feature actually needs. Describe what you want to build and it handles the manifest.
Build it without the setup.
Describe the extension you want and Extension Coder builds it, previews it live, and helps you publish.
Start building