Publishing to the Chrome Web Store

Publishing your extension to the Chrome Web Store is the standard way to distribute it to participants. Even if you set visibility to unlisted (so it is not searchable), publishing gives participants a clean install flow and lets Chrome verify the extension has not been tampered with.

Step 1: Register a Google Developer account

Go to https://chrome.google.com/webstore/devconsole and sign in with a Google account. There is a one-time $5 registration fee. If your lab or institution already has a developer account, you can use it instead.

Step 2: Package the extension

The Web Store expects a zip file containing your built extension. Build first, then zip:

npm run build
cd dist
zip -r ../my-study-extension.zip extension/

This creates my-study-extension.zip in the root of your project folder, containing the compiled extension. Do not zip the source files, only the dist/extension/ folder.

Set a minimum Chrome version

Before packaging, declare a minimum browser version in your manifest.json:

"minimum_chrome_version": "130"

Without this line, the Web Store offers the install to every Chrome version. A browser too old to understand a feature in your manifest then fails mid-install with the cryptic message “Download error: Invalid manifest”, which participants will report as the extension being broken. With the line, participants on older browsers instead see a clear “not compatible with your computer” message, and the fix (update Chrome) is obvious.

We recommend 130 for REX extensions. REX modules use extension APIs introduced as late as Chrome 130 (chrome.storage.local.getKeys()), and because Chrome updates itself silently, anyone on a supported operating system is well past that version. The only browsers a 130 floor excludes are those pinned by an operating system Chrome no longer supports: Windows 7/8.1 (stuck at Chrome 109) and macOS 10.15 and earlier (stuck at Chrome 128 or below), machines that could not run a study reliably anyway. Edge respects the same field at the matching Chromium version.

If a module you use adopts a newer API, raise the floor to match. The declared minimum is a promise that every feature in the bundle works there.

Watch for developer-mode-only features

Some Chrome extension features work only in unpacked extensions (the ones you load through Load unpacked in developer mode) and not in extensions installed from the Web Store. Because all local development happens unpacked, one of these can sit in your manifest for months without a single symptom, then surface for the first time at store submission or, worse, silently do nothing for participants.

The one that has bitten REX extensions in practice is the declarativeNetRequestFeedback permission: it exists for debugging declarativeNetRequest rules and is only honored in unpacked extensions. It reached a manifest not by anyone typing it, but through a dependency’s suggested configuration. Other examples of the same trap are localhost script sources in the CSP (allowed for unpacked extensions in Chrome 110+, never for store installs) and anything Chrome’s documentation marks “unpacked” or “requires developer mode”.

Before uploading, read the final built manifest (dist/extension/manifest.json, not your source file) and confirm every permission in it is one you can justify to a reviewer and that none is documented as unpacked-only. Testing the zipped, store-installed build at least once catches the remaining cases that an unpacked test never will.

Step 3: Upload the extension

In the Chrome Web Store developer dashboard, click New Item.
Upload the zip file you just created.
Fill in the store listing: name, description, screenshots, and category. These can be sparse for a research extension: focus on being clear about what the extension does and who it is for.

Step 4: Set visibility

Under Distribution, choose who can install the extension:

Unlisted: the extension does not appear in store search results. Only people with the direct link can install it. This is the recommended option for most research studies. You share the install link with your participants directly.

Private (group publishing): the extension is only available to specific Google accounts or a Google Workspace domain (such as a university domain). Use this for organization-managed deployments where participants are members of a controlled Google Workspace.

Avoid publishing as Public unless you specifically want your extension to be discoverable by anyone.

Step 5: The review process

Google reviews all extensions before they are published, including unlisted ones. Typical review time is a few days to a week.

Research extensions sometimes get flagged because they request broad permissions: access to browsing history, tabs, and page content. If your extension is held for review or rejected, write a clear explanation of the research purpose in the review notes. Reviewers are generally reasonable when the purpose is explained; the problem is usually that the submission did not provide enough context.

Keep your store description and permissions justification accurate. Do not request permissions your extension does not use.

Step 6: Distributing to participants

Once the extension is published, go to the store listing page and copy the URL. That URL is what you give to participants.

When a participant clicks the link, they will land on the Chrome Web Store listing page. They click Add to Chrome, then confirm the permissions dialog that appears. The extension installs immediately: no developer mode or technical steps required on their end.

Include the install link in your participant onboarding materials along with clear instructions about what to expect during installation. See Participant Onboarding.