Every Chrome extension lists the permissions it needs. Pick a permission to see exactly what it allows, the risk level, and whether you should worry.
Lets the extension save and read data locally in Chrome's extension storage. The data is scoped to the extension — other extensions and websites cannot read it.
Describe what you want in plain English. PlugThis generates a working Manifest V3 Chrome extension in under two minutes.
Open the builderEvery Chrome extension lists the permissions it needs in its manifest. These permissions determine what the extension can do — read your tabs, modify your bookmarks, intercept network requests, access cookies, send notifications, and so on.
When you install an extension, Chrome shows you the permissions it needs. Most users click through without reading. That's a mistake — those permissions are real powers being granted to code that runs in your browser on every site you visit.
One — does the permission match the function? A note-taking extension that requests <all_urls> (run on every site) is suspicious. A password manager that requests it is reasonable.
Two — how risky is the permission? Some permissions (like storage) are low-risk; they let the extension save its own data. Others (like webRequest) are high-risk; they can observe every network request your browser makes.
Three — is the developer trustworthy? Permissions in the hands of a reputable developer are different from the same permissions in the hands of an unknown one. Check who built the extension and how long it has been on the Web Store.
If you're building your own Chrome extension, request only the permissions your extension actually needs. Two reasons:
Chrome Web Store review. Extensions requesting broad permissions get more aggressive review. Asking for <all_urls> when you only need a specific domain triggers questions.
User trust. Users see the permission list before installing. A long list with scary-sounding permissions reduces install rates. Keep it minimal.
When in doubt, choose the more constrained option. Use activeTab instead of tabs. Use https://example.com/* instead of <all_urls>. Use declarativeNetRequest instead of webRequest.
They are as safe as the developer behind them. The permission itself defines what an extension can do; whether that capability is used responsibly depends on who built and maintains the extension. Treat permission lists as a "what could go wrong" inventory, not a safety guarantee.
More answers below.
Broad host permissions like <all_urls> combined with scripting or webRequest are the most dangerous combination. They let an extension read and modify every site you visit. Cookies permission on sensitive domains (banking, email, work tools) is also high-impact because cookies contain logged-in session tokens.
More answers below.
Indirectly, yes — any extension running on a site you log into can read what you type into form fields (via scripting + host permissions). Password managers do this intentionally. A malicious extension can do the same. This is why <all_urls> + scripting is treated as high-risk.
More answers below.
<all_urls> is a host permissions match pattern that grants the extension access to every URL Chrome can navigate to. Combined with the scripting permission, the extension can inject JavaScript and CSS into any page you visit. It is the most powerful host scope and should only be granted to extensions you fully trust.
More answers below.
For some permissions, yes. Chrome lets you change site access for an installed extension (chrome://extensions → Details → Site access) to 'on click' or specific sites only. API permissions like storage or tabs can't be revoked individually — to drop them, uninstall and reinstall a different extension that asks for less.
More answers below.
Generate a valid Chrome extension manifest.json in seconds. Pick permissions, content scripts, and pages — copy the result, drop it in your extension.
Describe a workflow you want to improve. Get 3 tailored Chrome extension ideas you can build in under 10 minutes.