How to Publish an Extension to Microsoft Edge Add-ons (2026)

You already ship a Manifest V3 Chromium extension. The next step to reach Microsoft Edge users is to publish an edge extension on the Microsoft Edge Add-ons store (the edge extension store). That pipeline runs in Partner Center, separate from the Chrome Web Store even when the zip is nearly identical.

Search Console already sends turbostarter.dev hundreds of impressions for Edge Add-ons queries, mostly to our Edge publishing docs. This post is the end-to-end walkthrough those docs complement. If you are shipping web, mobile, and extension from one monorepo, pair it with cross-platform SaaS architecture and versioning across surfaces.

TL;DR checklist

Who this guide is for

You have a working Chromium extension (often already on the Chrome Web Store) and you want it discoverable on microsoft edge add-ons or distributed via a hidden listing URL for beta testers. You do not need a separate backend tutorial here, though production extensions almost always call an API. TurboStarter's extension kit docs cover auth and deployment; this article focuses on Microsoft's publishing pipeline.

Microsoft Edge Add-ons developer account (Partner Center)

Registration fee and account types

Microsoft states clearly: There is no registration fee for submitting extensions to the Microsoft Edge program (create dev account).

You enroll through Partner Center with a Microsoft account (MSA) (Outlook.com, Live.com, or Hotmail.com). GitHub sign-in is also supported; Partner Center can create an MSA for you (create dev account). Work or school accounts alone are not supported for initial registration; you link Microsoft Entra tenants later for team access.

In the Edge Developer Account Registration form you choose:

Important: Account country/region and account type cannot be changed after enrollment. Company accounts cannot switch to individual accounts (create dev account).

Verification and publisher display name

After you accept the developer agreement and click Finish, Microsoft verifies enrollment and emails you when the account is ready (create dev account). Company accounts may need legal documents under Account settings | Legal info.

Publisher display name (company name) is shown on the edge add-ons store listing, max 50 characters, and must be available and yours to use (create dev account).

Do you need a company account?

No. Individuals publish on microsoft edge add-ons every day. Choose Company only when you must list a registered legal business name and can complete approver verification.

Prepare your extension package

Manifest V3 and zip layout

Edge supports the same Chromium extension model as Chrome. Your uploaded .zip must include the manifest and all packaged assets (publish extension).

Before upload, confirm manifest fields that flow into the store listing:

Microsoft recommends a short description in the manifest so the listing does not repeat the first lines of the long description (publish extension).

Example MV3 manifest skeleton:

{
  "manifest_version": 3,
  "name": "My SaaS Assistant",
  "version": "1.0.0",
  "description": "Connects your browser to your TurboStarter backend.",
  "short_name": "Assistant",
  "action": {
    "default_popup": "popup.html",
    "default_icon": {
      "128": "icons/icon-128.png"
    }
  },
  "permissions": ["storage"],
  "host_permissions": ["https://api.example.com/*"]
}

Zip only the build output folder contents with manifest.json at the root:

cd apps/extension/.output/chrome-mv3
zip -r ../edge-submission.zip . -x "*.map"

If you use WXT, run your production build first. TurboStarter maps package.json version into the manifest on build (extension versioning recipe).

Port a Chrome Web Store extension to Edge

Most Chrome MV3 extensions port with minimal edits (port Chrome extension):

1. Compare APIs you use with Microsoft Edge API support.
2. Remove update_url from manifest.json (Chrome Web Store update endpoint).
3. Replace Chrome branding in the name or description with Microsoft Edge where required for certification.
4. Sideload locally to verify behavior (sideload guide).
5. If you use chrome.runtime.connectNative, set allowed_origins to chrome-extension://[your-edge-extension-id] in the native messaging host manifest after Edge assigns an ID.

What usually carries over unchanged: MV3 structure, content scripts, service worker, most chrome.* APIs Edge implements, and store graphics (with size rules below).

What differs: separate Partner Center product, certification forms (single purpose, permission justification, data usage), and Edge-specific listing fields. You still need distinct listings on Chrome, Firefox, and Edge even from one codebase (WXT + Vite extension stack).

Store listing assets (Microsoft Edge Add-ons)

Upload graphics per language on the Store listings pages in Partner Center (publish extension Step 7):

Manifest name and description are read-only on the listing UI after upload; change them in the package and re-upload the zip (publish extension).

Submit to the edge extension store step by step

Create the extension and upload the package

1. Open Partner Center and the Edge workspace (publish extension).
2. Click Create new extension and upload your .zip.
3. Fix validation errors, then continue through Packages and Extension overview.

Availability and markets

On Availability (publish extension Step 4):

Markets default to all markets (including future markets). Users who installed while a market was enabled keep the extension if you later remove that market, but they may not receive updates published only for remaining markets (publish extension).

Properties and privacy

Properties include category (required), optional website and support URLs, and mature content flag (publish extension Step 5).

Privacy is where certification often stalls (publish extension Step 6):

• Single purpose description matching real behavior.
• Permission justification for each manifest permission (remove unused permissions first).
• Remote code: MV3 does not allow remotely hosted executable code; select No unless you are on MV2 (publish extension).
• Data usage checkboxes and certifications aligned with your policy.
• Privacy policy URL when you collect personal information (developer policies).

Align disclosures with your SaaS privacy page. See extension auth overview if the extension handles session tokens.

Certification notes and publish

When store listings show Complete, click Publish and open Submit your extension (publish extension Step 8).

In Notes for certification, include:

• Test account credentials.
• Steps to reach gated features.
• Regional behavior differences.
• What changed if this is an update.

Click Publish again to enter certification. Microsoft states the process can take up to seven business days. After approval, status becomes In the Store on Microsoft Edge Add-ons.

Edge extension certification and common rejections

Microsoft's pipeline includes preprocessing scans, security checks, and human policy review (Edge publishing docs, add-ons curation).

Rejections arrive by email and appear on the Certification report page. Fix issues, bump version, upload a new package, and submit again (Edge publishing docs).

Microsoft does not publish a shorter "typical" review window than the up to seven business days statement in the publish guide. Plan release comms accordingly.

Update an Edge extension

Every new package needs a higher version in manifest.json than the build in the store (publish extension). Upload via Partner Center Packages or the REST API, refresh privacy fields if permissions changed, update certification notes for testers, and publish again.

TurboStarter's extension updates doc recommends bumping package.json version before each store upload. Breaking permission changes often require manual Partner Center metadata even when CI uploads the zip (Edge publishing docs).

Automate with the Microsoft Edge Add-ons API

The REST API updates existing products only. You cannot create a new extension or edit listing metadata through the API (using Add-ons API). The first submission stays manual so you obtain the product ID (GUID) and complete listing metadata (Edge publishing docs).

Enable API credentials (v1.1)

1. Partner Center → Microsoft Edge program → Publish API.
2. Click Enable for the new experience (API keys).
3. Click Create API credentials and save Client ID and API key immediately (using Add-ons API).

Root endpoint: https://api.addons.microsoftedge.microsoft.com.

Typical update flow:

1. POST /v1/products/{productID}/submissions/draft/package with zip body (headers: Authorization: ApiKey {key}, X-ClientID: {clientId}).
2. Poll package operation status until complete.
3. POST /v1/products/{productID}/submissions with JSON notes to publish.
4. Poll publish operation status.

Example upload (replace placeholders):

curl \
  -H "Authorization: ApiKey $EDGE_API_KEY" \
  -H "X-ClientID: $EDGE_CLIENT_ID" \
  -H "Content-Type: application/zip" \
  -X POST \
  -T ./edge-submission.zip \
  "https://api.addons.microsoftedge.microsoft.com/v1/products/$EDGE_PRODUCT_ID/submissions/draft/package"

CI example (GitHub Actions + WXT)

TurboStarter ships .github/workflows/publish-extension.yml with Edge secrets (Edge publishing docs):

env:
  EDGE_PRODUCT_ID: ${{ secrets.EDGE_PRODUCT_ID }}
  EDGE_CLIENT_ID: ${{ secrets.EDGE_CLIENT_ID }}
  EDGE_API_KEY: ${{ secrets.EDGE_API_KEY }}

Run npx wxt submit with --edge-zip after the first manual approval. Use --edge-skip-submit-review when you only want upload without sending to certification (WXT submit, Plasmo BMS Edge tokens).

The GitHub Marketplace Publish Edge Add-on action wraps the same API for workflows that do not use WXT.

Ship Chrome, Firefox, and Edge from one codebase

Each marketplace is its own account, review, and listing URL. Shared engineering wins come from one MV3 source tree, shared auth against your TurboStarter backend, and aligned versioning (software versioning across surfaces).

Use the publishing checklist before you tag a release.

How TurboStarter fits in

TurboStarter Core is a production-ready SaaS starter kit across Next.js web, Expo mobile, and a WXT browser extension on one Better Auth backend. Publishing is not a separate product: you get store-ready zips, shared API types, and docs that mirror the steps in this article.

What the kit documents today:

• Manual and automated Edge publishing, including first-upload requirements and GitHub Actions secrets (Edge Add-ons).
• Parallel Chrome and Firefox guides when you expand beyond one store (Chrome blog).
• Pre-submission checklist for API URLs, assets, and store accounts (publishing checklist).
• Version bumps via package.json before each upload (updates).

Use this post for policy context and official Microsoft links. Use /docs/extension/publishing/edge when you are inside the repo running builds. If you are evaluating kits, see Core pricing and the extension stack page.

FAQ

Takeaway

Publish an edge extension by treating Microsoft Edge Add-ons as its own release channel: enroll in Partner Center (no Microsoft registration fee), ship a clean MV3 zip, be precise about privacy and permissions, complete per-language store assets, and plan for certification that may take up to seven business days. Automate uploads only after the first manual submission passes review. If you want the extension client already wired to your SaaS backend, TurboStarter Core ships the WXT app, store docs, and CI patterns so you can focus on the product inside the popup, not on rediscovering Partner Center labels every release.