Publishing to Microsoft Edge Add-ons

Edge users can install from the Chrome Web Store after flipping a setting, so why publish on Microsoft Edge Add-ons at all? Because many don’t flip it, because Edge’s own store surfaces extensions to Edge users in search and recommendations, and above all because enterprises that standardise on Edge often allow only Edge Add-ons as an extension source. The good news is that an MV3 extension that runs in Chrome almost always runs unchanged in Edge — the work is in the account, the listing and the release process. This guide walks through it. It belongs to store submission and permissions compliance.

What is the same and what differs

Edge is built on Chromium, so the extension package — manifest, service worker, content scripts, chrome.* APIs — is the same one you upload to the Chrome Web Store. The differences are around it. Publishing happens through Microsoft Partner Center with its own developer registration. The listing has its own fields, categories, images and privacy policy requirements, and its own certification (review) process and timelines. The published extension gets an Edge-specific extension id, different from the Chrome Web Store id, which affects anything that recognises the extension by id: OAuth redirect URLs, native messaging host manifests, externally_connectable calls from your website and server-side allow-lists. And Google-specific services such as chrome.identity.getAuthToken behave differently in Edge.

Step-by-step: publish and keep it updated

1. Register in Partner Center

Create (or use) a Microsoft Partner Center account and enrol in the Microsoft Edge program. Registration is free; individual and company accounts are supported. Complete the publisher profile — the publisher name appears on the listing, so use the same name as on the Chrome Web Store to help users recognise you.

2. Test the package in Edge first

1# Load the same build Chrome uses
2msedge --load-extension="$(pwd)/dist/chrome" --user-data-dir=/tmp/edge-test

Execution context: a terminal with Edge installed. Run your end-to-end suite against Edge as well as Chrome; Playwright’s Chromium channel can be pointed at Edge with channel: "msedge". Pay attention to sign-in flows, anything using Google services, and UI that depends on Chrome-specific browser chrome.

1// playwright.config.js
2projects: [{ name: "edge", use: { channel: "msedge" } }]

Execution context: test configuration. Extension loading in Edge works the same way as in Chromium with --load-extension in a persistent context.

3. Create the submission

In Partner Center, create a new extension, upload the zip, and fill in the listing: description (Markdown-like formatting), category, screenshots, logo, search terms, and a privacy policy URL if the extension handles personal data. Answer the availability questions — markets and visibility (public, or hidden for a private audience). Provide notes for certification testers: test credentials and steps to reach paid features, exactly as you would for Chrome review.

4. Handle the Edge extension id

1// shared/ids.js — every external system needs both ids
2export const EXTENSION_IDS = {
3  chrome: "abcdefghijklmnopabcdefghijklmnop",
4  edge:   "ponmlkjihgfedcbaponmlkjihgfedcba",
5};
6// OAuth redirect URIs to register:
7//   https://abcdefghijklmnopabcdefghijklmnop.chromiumapp.org/
8//   https://ponmlkjihgfedcbaponmlkjihgfedcba.chromiumapp.org/

Execution context: shared configuration for your website and backend. After the first Edge submission, Partner Center shows the extension’s Edge id. Register its chromiumapp.org redirect with your OAuth provider, add it to native messaging host manifests’ allowed_origins, and to any externally_connectable callers on your website. The key field cannot make the Edge id match the Chrome one — the store assigns it. See supporting Edge, Opera and Brave.

5. Automate updates with the Edge Add-ons API

1# Upload a new package to an existing product, then submit for certification
2curl -s -X POST "https://api.addons.microsoftedge.microsoft.com/v1/products/$EDGE_PRODUCT_ID/submissions/draft/package" \
3  -H "Authorization: ApiKey $EDGE_API_KEY" -H "X-ClientID: $EDGE_CLIENT_ID" \
4  -H "Content-Type: application/zip" --data-binary @dist/chrome.zip -D - | grep -i location
5
6curl -s -X POST "https://api.addons.microsoftedge.microsoft.com/v1/products/$EDGE_PRODUCT_ID/submissions" \
7  -H "Authorization: ApiKey $EDGE_API_KEY" -H "X-ClientID: $EDGE_CLIENT_ID" \
8  -H "Content-Type: application/json" -d '{"notes":"Release 2.6.0 — see changelog"}'

Execution context: CI with API credentials generated in Partner Center, stored as secrets. The first submission of a product must be made through Partner Center; later updates can be fully automated. Upload responses include an operation location you can poll for validation status before submitting. See publishing to Edge Add-ons from CI.

6. Plan for certification timelines

Edge certification is separate from Chrome review and can take a different amount of time; plan releases assuming the two stores publish on different days. For urgent fixes, rely on remote feature flags to mitigate on both stores immediately while each review proceeds.

7. Serve enterprise customers

Enterprise administrators deploy Edge extensions with Edge policies (ExtensionInstallForcelist with the Edge Add-ons update URL) and configure them through managed storage under Edge’s policy paths. Document the Edge id and policy snippets alongside the Chrome ones in your admin guide.

Common mistakes

• Assuming the Edge id equals the Chrome id. It doesn’t; register both everywhere.
• Relying on getAuthToken. Use launchWebAuthFlow for sign-in in Edge.
• Different version numbers per store. Keep one version per release for support sanity.
• Skipping Edge testing. Rare differences still appear in sign-in and Google-service features.
• Forgetting enterprise docs. Edge-managed fleets need the Edge id and policy paths.

Keep listings consistent across stores

Users often compare stores. Use the same name, icon, screenshots and core description on the Chrome Web Store and Edge Add-ons, adapting only store-specific fields. Consistent listings build trust, make support simpler, and let a single screenshot pipeline feed both stores. Note Edge-specific details where they matter — for example, that enterprise customers should deploy from Edge Add-ons — rather than maintaining two divergent descriptions that drift apart release by release.

Cross-browser variation

• Chrome: Chrome Web Store, CWS id, Chrome Web Store API.
• Edge: Edge Add-ons, separate id, Partner Center and Edge Add-ons API; Edge users can also install from the Chrome Web Store with a setting enabled, which gives them the Chrome id.
• Firefox / Safari: separate packaging and stores entirely; see publishing to Firefox Add-ons and Safari.

Verification

1. Install from Edge Add-ons and confirm chrome.runtime.id is the Edge id shown in Partner Center.
2. Sign in from the Edge install and confirm the OAuth flow completes.
3. Run CI’s Edge upload against a test product and confirm the submission appears in Partner Center.
4. Confirm your website and native host recognise both ids.

FAQ

Should I publish to Edge if users can use the Chrome Web Store?

Yes, if you have business users or want visibility in Edge’s store. It costs little once automated.

Can users with both installs see duplicates?

A user who installs both versions has two separate extensions with separate storage. It is rare; mention it in support docs.

Does Edge support all MV3 APIs Chrome does?

Nearly all. Feature-detect anything new or Google-specific.

What if certification rejects something Chrome accepted?

Read the certification report carefully — the stores’ policies overlap but are not identical, particularly around privacy disclosures and settings changes. Fix the issue in the shared package where possible so both stores receive the same code.

Related

• Passing Chrome Web Store review — the review habits that also help in Edge certification.
• Supporting Edge, Opera and Brave — runtime differences in Chromium browsers.
• Publishing private and enterprise extensions — managed distribution.
• Store submission and permissions compliance — the parent topic.