- Outcome
- A tested Edge submission package
- Store lens
- Microsoft Edge Add-ons
- Reading time
- 10 minutes
Branch from a known Chrome build
Microsoft says Chrome extension APIs and manifest keys are largely code-compatible with Edge, but you must review API support and browser-specific behavior.
Keep shared source where practical while producing a separately tested store artifact. Record which differences are configuration, assets, copy, or code.
Apply Edge-specific package changes
Microsoft's porting guidance says to remove the Chrome Web Store update_url value before packaging for Edge. Review browser branding in the extension name, description, UI, help, and screenshots.
Do not add Firefox-specific manifest claims: ExtensionGate's current public scanner scope is Chrome and Microsoft Edge only.
Synthetic example
// Synthetic Edge manifest adjustment
{
"manifest_version": 3,
"name": "Example Helper",
"version": "2.4.0"
// Chrome Web Store update_url removed
}
Sideload and test in Edge
Load the unpacked build in a clean Edge profile. Exercise onboarding, primary purpose, service worker wakeups, authentication, permissions, optional access, settings, update behavior, and external links.
Check every API against Microsoft's support documentation. Test failures explicitly rather than assuming Chromium parity.
Prepare Partner Center evidence
Microsoft's publishing workflow accepts a ZIP and asks for listing details, markets, privacy information, permission justifications, remote-code details, and certification notes.
Make gated functionality testable and provide reviewer instructions or credentials through the designated store workflow. The package, listing, privacy answers, and real behavior should tell the same story.
Official sources
- Microsoft: port a Chrome extension to Edge
- Microsoft: publish an Edge extension
- Microsoft Edge extension developer policies
Sources and guidance were human-reviewed on . Store forms and policies can change; verify them again at submission time.