← Back to Chrome Extension Permission Checker
Reading manifest.json alongside your source and searching for each declared
permission's API calls genuinely works, and it is the method most extension developers already
use before a submission. This page names no product or company being compared against:
"checking the manifest by hand" is a generic manual habit, not a competing tool.
| Case | Checking the manifest by hand | This tool |
|---|---|---|
A permission with one obvious code shape, e.g. chrome.storage.* | Correctly caught by a search for the pattern | Correctly caught the same way |
clipboardRead, which is either navigator.clipboard.readText() or document.execCommand('paste') | Searching for one pattern and not finding it reads as "unused" even when the other is present | Checks both known signatures for every permission that has more than one |
A host pattern listed inside permissions rather than a separate host_permissions array (Manifest V2 style) | Easy to skim past as an ordinary API permission entry | Reads a host pattern wherever it appears and checks it against the same broad-pattern set |
A newly added chrome.* call whose permission was never added to the manifest | Requires diffing the whole source tree against the manifest again after every change | Re-scans every file given each run, regardless of which one changed |
| A permission with no checkable code signature (ChromeOS/enterprise-only) | No way to tell "not checked" from "confirmed unused" without reading the tool's own documentation | Reports these explicitly as not checked rather than guessing |
Not every permission has a single, unambiguous API call to search for. clipboardRead
is unlocked by either the modern navigator.clipboard.readText() or the older
document.execCommand('paste'), and a codebase can use either. A developer who
searches for only one and comes up empty will report the permission unused -- the wrong
conclusion if the other pattern is what the code actually uses. This tool checks every known
signature for a permission, not just the one a developer happened to think of first.
Manifest V2 extensions often list broad site-access patterns directly inside the
permissions array next to ordinary API permissions like storage and
tabs, with nothing to visually distinguish them. A skim for suspicious
chrome.* usage has no reason to single out an entry that is not an API permission at
all. This tool checks every host-shaped entry it finds, in either array, against the same fixed
broad-pattern list every time.
This tool answers whether a permission's code signature is present or absent in the source you point it at -- it has no opinion on whether the feature behind that signature is worth the scrutiny a broad permission invites in review, and Chrome Web Store review ultimately judges justification, not just presence. Deciding whether a permission is actually needed, and writing the justification review will ask for, is still a job for you.
A developer who remembers to look can spot an obviously unused permission -- a leftover storage entry from a feature that got removed, say -- by scanning the source for chrome.storage. and not finding it. That review genuinely works for a small codebase with permissions whose API surface is a single, obvious pattern, which is most of them.
clipboardRead has two unrelated code shapes that both use it: the modern navigator.clipboard.readText() call, and the older document.execCommand('paste'). A developer searching the source for one pattern and not finding it will conclude the permission is unused, when the code actually uses the other pattern. This tool checks both signatures for every permission that has more than one, so which one a codebase happens to use never matters.
Manifest V2 extensions commonly list host patterns like *://*.example.com/* directly inside the permissions array, alongside ordinary API permissions like storage and tabs -- there is no separate host_permissions array to signal which entries are which. A developer skimming the array for chrome.* API misuse has no visual cue that one entry is a broad site-access grant rather than an API permission, and might not think to check it against the broad-pattern list at all. This tool reads a host pattern wherever it appears -- in permissions or the newer host_permissions array -- and checks it against the same fixed broad-pattern set every time.
A used-but-undeclared permission -- code calling a chrome.* API whose permission was never added to the manifest -- fails at runtime, independent of review, and catching it means diffing every file against the manifest again after every change. That is easy to skip on a routine feature addition, especially right before a submission deadline when a developer is focused on the one file they just edited. This tool re-scans every file it is given every time, so a permission gap introduced anywhere in the tree is caught the same way regardless of which file changed.
No. This tool answers whether a permission's code signature is present or absent -- it has no opinion on whether the feature that signature supports is worth the review scrutiny a broad permission invites. Chrome Web Store review ultimately judges justification, not just presence, and that judgment call is still yours.