Microsoft Edge’s Chromium Relaunch: What It Meant for Extension Developers

Microsoft’s original Edge browser, built on the in-house EdgeHTML engine, shipped with Windows 10 in 2015 as the intended successor to Internet Explorer. By late 2018, Microsoft had quietly conceded that maintaining a third independent rendering engine against Chromium’s and Gecko’s combined market gravity was no longer sustainable, and announced it would rebuild Edge on Chromium. The new browser reached general availability on January 15, 2020. For extension developers, the change was one of the more consequential platform shifts of the era — not because it introduced anything novel, but because it eliminated an entire compatibility target almost overnight.

What EdgeHTML’s Extension Model Actually Was

Understanding why the Chromium switch mattered requires understanding what extension developers were dealing with before it. EdgeHTML Edge supported a version of the WebExtensions API — the same general model Firefox and Chrome extensions use — but Microsoft’s implementation diverged in enough particulars that most non-trivial extensions required a dedicated Edge-specific build, submitted through the Microsoft Store, using a packaging and manifest format that didn’t fully align with Chrome’s.

For a browser with a genuinely small market share at the time, this created a rational calculation most extension developers made without much agonizing: build for Chrome and Firefox, where the combined user base justified the engineering effort, and skip EdgeHTML Edge entirely unless a specific business reason demanded otherwise. The result was that EdgeHTML Edge shipped with a real, working extension platform that most of the ecosystem simply ignored.

What Changed at Launch

The Chromium-based Edge that launched in January 2020 runs on the same rendering and extension engine as Chrome. Concretely, for extension developers, that meant:

Chrome Web Store extensions work with minimal or no modification. Because Chromium Edge implements the same chrome.* extension APIs as Chrome itself, an extension packaged for the Chrome Web Store generally installs and runs correctly in Edge without a separate build. Microsoft went further and added a compatibility feature that let users install extensions directly from the Chrome Web Store from within Edge’s own extension settings, rather than requiring a parallel Microsoft Store listing.

The Microsoft Edge Add-ons store still exists as a separate distribution channel, with its own review process, but developers are no longer required to maintain a second codebase to reach it — the same package that targets Chrome typically works.

Manifest V2 extensions worked exactly as they did in Chrome, and later, as Chrome moved toward Manifest V3, Edge tracked the same platform changes on the same rough timeline, since both browsers share the underlying Chromium extension implementation.

For a developer maintaining a cross-browser extension, the practical effect was that “Chromium-based” stopped being a synonym for “Chrome” and became a genuine platform category — Chrome, Edge, and other Chromium derivatives could largely be treated as one target, distinct only from Firefox’s Gecko-based implementation, which retained its own extension API surface and behavioral quirks. It’s the same underlying shift toward one dominant engine family that also stood behind Chrome’s SameSite cookie default change a few months earlier landing as a de facto web-wide standard rather than a single-browser quirk — once one Chromium implementation adopts a behavior, it effectively becomes the behavior for every Chromium-based browser at once.

What Microsoft Actually Added, Not Just Inherited

Microsoft didn’t just rebase Edge on Chromium and stop. Some Edge-specific features layered on top of the shared engine are relevant to developers building for the platform specifically:

Collections and vertical tabs are Edge-specific UI features that don’t correspond to any extension API most developers need to account for, but they do mean Edge’s chrome (the browser UI, not to be confused with Google’s browser) diverges visually and behaviorally from stock Chromium in ways that can affect how an extension’s UI elements — browser action popups, sidebar panels — appear alongside Edge’s own interface.

Tracking prevention levels, Edge’s built-in anti-tracking feature, ships with three tiers (Basic, Balanced, Strict) similar in spirit to Firefox’s Enhanced Tracking Protection modes, and can interact with extensions that also attempt to modify network requests or inject content — a source of occasional double-blocking or conflicting behavior between a user’s chosen tracking prevention level and a separately installed content blocker.

Enterprise policy support was a major point of emphasis for Microsoft’s push into corporate deployment, and extension developers targeting business customers needed to understand Edge’s specific group policy templates for extension allowlisting and forced installation, which differ in structure from Chrome’s equivalent enterprise policies even though the underlying extension platform is shared.

The Compatibility Reality, Two Years In

By the time the dust settled, the practical developer experience converged on a simple rule of thumb: build and test against Chrome, verify in Edge as a lightweight compatibility pass rather than a separate development effort, and expect the vast majority of Manifest V2 (and later V3) extensions to just work. The exceptions were extensions relying on browser-specific APIs Microsoft hadn’t implemented, edge cases in permission dialog behavior, and extensions that assumed Chrome-specific update or installation flows the Microsoft Store’s review process handled differently.

This was a genuine, measurable reduction in the cross-browser maintenance burden for the extension ecosystem as a whole. Three independent extension platforms (Chrome, EdgeHTML Edge, Firefox) effectively became two (Chromium-family, Firefox) almost overnight, and the practical significance of that consolidation compounds every time a developer decides whether a fourth browser is worth a dedicated build.

Internet Explorer Mode: The Enterprise Compatibility Bridge

One Edge-specific feature deserves separate mention because it created a genuinely unusual environment for anyone testing extensions in enterprise contexts: IE mode, a compatibility feature that lets Edge render specific, administrator-designated sites using the legacy Internet Explorer 11 engine embedded within the Chromium browser shell. Microsoft built this specifically to give large enterprises, many of which had internal line-of-business web applications built years earlier against IE-specific behavior, a path to retire standalone Internet Explorer entirely while still supporting those legacy applications during a transition period.

For extension developers, IE mode matters because a tab rendering in IE mode does not run Chromium extensions against that tab’s content — content scripts targeting <all_urls> will not execute against an IE-mode page the way they would against a normal Chromium-rendered tab, since the underlying rendering engine for that specific tab isn’t Chromium at all. This is a narrow but real edge case for extension developers building for enterprise deployments: testing exclusively against consumer Edge configurations can miss IE-mode-specific gaps that only surface once an extension is deployed into a corporate environment where administrators have designated certain internal sites for legacy rendering.

What It Meant for the Broader Engine Diversity Conversation

The flip side of this consolidation, and one worth naming honestly, is that it reduced the number of independent browser engines in meaningful production use from three to effectively two (Chromium and Gecko), plus Safari’s WebKit. Fewer independent engines means fewer independent implementations checking each other’s interpretation of web standards, which is a real concern for the health of the open web even as it’s a practical convenience for any individual extension developer targeting the largest possible user base. Edge’s move to Chromium was a rational business decision for Microsoft and a genuine convenience for developers — and it was also one more data point in a broader trend of engine consolidation that standards bodies and independent-browser advocates have flagged as a long-term risk to how the web evolves.

FAQ

Do I still need to submit my extension separately to the Microsoft Store? Not strictly, for most extensions. Users can install directly from the Chrome Web Store within Edge’s extension settings. A separate Microsoft Store listing is still worthwhile for discoverability within Edge specifically, and for extensions that want to go through Microsoft’s own review and certification process, but it is not required for basic compatibility.

Does Edge support Manifest V3 the same way Chrome does? Largely yes, since both share the same underlying Chromium extension implementation and generally track the same platform timeline. Minor differences in rollout timing and specific enterprise policy support exist, but the core API surface — service workers, declarativeNetRequest, runtime-grantable host permissions — behaves the same way.

Is Edge’s built-in tracking prevention the same as an extension-based content blocker? No. Tracking prevention is a native browser feature operating at the network-request level with its own tiered settings, conceptually similar to Firefox’s Enhanced Tracking Protection. It can run alongside a separately installed content-blocking extension, though the two can occasionally interact — for example, both attempting to block the same request through different mechanisms.

Did any EdgeHTML-only extensions fail to make the transition? Yes. Extensions that depended on EdgeHTML-specific APIs Microsoft never carried forward to the Chromium build had to be substantially rewritten or were discontinued. This was a relatively small population, since EdgeHTML’s extension ecosystem was thin to begin with, precisely because of the compatibility gap that motivated the rebuild.

Is Chromium Edge’s extension platform identical to Chrome’s in every respect? Nearly, but not perfectly. Edge layers its own enterprise policy structure, some UI-level differences (Collections, vertical tabs, sidebar behavior) that can affect how extension UI elements render alongside them, and its own store review process on top of the shared Chromium extension engine. For the overwhelming majority of extensions, these differences don’t require code changes — but they’re worth knowing about before assuming zero-effort parity for every feature.