Understanding Chrome extension permissions

Two different lists

Almost every confusion about permissions comes from treating them as one thing. A Manifest V3 file can declare three separate lists, and they answer different questions:

Most extensions need both. A password manager needs storage to keep its vault settings and host access to the sites you use it on. Neither half tells you anything on its own.

API permissions

These are named after Chrome's own API namespaces. Each one unlocks a specific group of functions, and the name maps to what it does:

• storage — the extension's own settings and cached data. Nearly every extension needs it, and on its own it is about as broad as a permission gets.
• tabs — read the URL and title of every open tab. Necessary for tab managers, and also the reason a tab tool can see where you have been.
• history — read your browsing history.
• cookies — read and change cookies, for sites the extension has host access to.
• bookmarks, downloads, topSites — the obvious things.
• clipboardRead — see anything you copy, including a password you paste into a form.
• webRequest — observe network requests, including URLs and headers.
• debugger — attach a debugger to tabs. Extremely broad, and legitimately needed by developer tooling.

Some API namespaces need no declaration at all — runtime, i18n,commands and types are available to every extension. Seeing one of those in a manifest is harmless.

Host permissions

Host permissions are match patterns, and they decide which pages an extension can see or change. They are worth reading carefully, because this is usually where the real reach is:

• https://example.com/* — one site. Narrow and specific.
• https://*.example.com/* — that site and its subdomains.
• https://*/* — every https site on every host. Very broad.
• <all_urls> — every site including http and local files. The broadest grant available.
• file:///* — files on your own machine that you open in the browser.

Note what host access does and does not do. It lets an extension read and change content on matching pages — and inject scripts into them. It is not a read-only grant and it is not sandboxed per page.

What "high-impact" means, and what it does not

Descriptors like narrow, moderate and high-impact describe the breadth of the capability and nothing else. High-impact permissions are the ones that reach across surfaces: all tabs, all browsing history, request blocking, debugger attachment.

A powerful permission is not evidence of a problem. Password managers, ad blockers, accessibility tools, translators and page enhancers all need broad access, because working across arbitrary websites is the entire job. What is worth doing is checking whether a specific permission makes sense for what the extension claims to do. A tab manager that reads history, or a notes tool that wants debugger, is the interesting case — not the existence of tabs or storage on its own.

The reverse also holds: a small permission list is not a clean bill of health. Behaviour lives in code, and code is not described by a permission.

Optional permissions

optional_permissions and optional_host_permissions are not granted at install time. The extension has to ask, Chrome shows the user exactly what is being requested, and declining costs nothing — nothing is uninstalled. This is the mechanism Manifest V3 introduced so that an extension can request a site only when you actually use the feature there.

A reader mode that needs access to one article site, asked for on that site and only then, is optional permission working as designed.

activeTab is worth understanding

activeTab grants temporary access to the tab you are looking at, and only after you invoke the extension — by clicking its toolbar button or using a keyboard shortcut. It expires when you navigate away.

It exists precisely so that a popup extension can act on the current page without asking for every site permanently. If an extension holds activeTab instead of broad host access, that is a deliberate and more privacy-preserving design choice.

How to check an extension's permissions yourself

1. Get the manifest. The Manifest Viewer reads it out of a CRX or ZIP in your browser, or from pasted text.
2. Read permissions and host_permissions separately. ThePermission Checker shows what each entry allows and its category.
3. Look at the <all_urls> and https://*/* entries first. They decide the blast radius.
4. Then check whether anything about the list is odd for the extension's stated purpose. That comparison is the actual judgement, and it is yours to make.

For a wider view of an extension beyond its permissions, theExtension Inspector summarises background configuration, content scripts and resources in the same pass.