What a browser extension can do, before you install it

Every answer you will find to this tells you to read the permission box Chrome shows when you click Add to Chrome, or to open chrome://extensions afterwards. Both of those are after you have decided. The extension is a zip file you can download and read first: its manifest.json lists exactly what it asks for, and its code names the advertising and analytics libraries it links and the addresses it talks to. MANIFEST opens a .crx, an .xpi or an extension zip in the browser and reads all of that, without installing it and without uploading it.

Why the install dialogue is not enough

The box Chrome shows is a summary written for a general audience, and it is a summary of the permissions only. Three things it does not tell you:

• What the code actually links. An extension that legitimately needs to read pages may also carry four analytics SDKs. Those do not appear in a permission list, because an SDK is not a permission; it is a library the extension chose to include, and it gives itself away by name in the code.
• Where it talks to. Addresses compiled into the extension as constants are the clearest statement of who it is in touch with, and none of them appear in the dialogue.
• What the wording means. “Read and change all your data on all websites” is accurate and it is also so broad that people have learned to click past it. In practice it means the extension can read your bank's pages as you see them, and rewrite them.

And the dialogue only appears at the moment you are already committed: you have found the extension, read the reviews, decided you want it, and clicked. That is the worst moment to be asked to evaluate a risk.

Reading the package instead

A Chrome or Edge extension is a zip behind a small CRX header. A Firefox add-on is a plain zip. Both contain a manifest.json in readable text that says, exactly and without interpretation, what the extension declares.

What to look at, in order:

• permissions and host_permissions. <all_urls> or *://*/* means every site you visit. Combined with webRequest or scripting, it means the extension can read and alter every page you load, including while you are logged in to anything.
• content_scripts and their matches. This is where an extension says which pages it injects code into. A shopping extension matching only retail domains is a different object from one matching everything.
• externally_connectable, which lets named web pages talk to the extension directly.
• Manifest version. A current extension is on version 3. Version 2 in 2026 means an unmaintained extension, and unmaintained is the state in which extensions get sold.
• The names in the code. An analytics or advertising library cannot be used without being referenced, so it appears in the strings. So do the hardcoded URLs.

Judging what you find

Permissions are claims about capability, not evidence of behaviour, and the question is never “is this permission alarming”. It is does this permission have an explanation in what the extension is for.

So write down what it claims to do, then account for each entry. A password manager needs broad access; a dark-mode toggle does not need your browsing history; a PDF viewer does not need your clipboard. The entries you cannot account for are the finding.

Then consider the two things that make extensions different from other software you install. They update silently, so what you approved is not necessarily what you are running next month. And they are bought and sold: a small, useful, honest extension with a good review history is a valuable asset precisely because of that history, and the update after a sale arrives without ceremony. An extension that was fine for three years is not evidence that it is fine now.

Getting the file to read

For Firefox, the .xpi is a direct download from the add-on page. For Chrome and Edge, the store does not offer a download link, so people use one of the several CRX-download services; whichever route you take, you end up with a file, and MANIFEST reads it in the tab without sending it anywhere.

That last part is not incidental. The sensible instinct with a suspicious package is to upload it to a scanner, and for an extension you suspect (or a pre-release build, or one belonging to a client) that may be something you are not free to do. Reading it locally is the version of this that you can always do.

The same question about an app

An Android APK works the same way and MANIFEST reads it too: the permission list is decoded from the binary XML that aapt writes, the exported components say what other apps on the device can reach without asking you, and the class names in the classes.dex files name every SDK the app links. It is the same exercise, and the answer is more often surprising.