Adblock detection on Microsoft Edge: the publisher guide

Microsoft Edge is the default browser on Windows, which means it carries a meaningful share of mainstream and enterprise traffic to most publisher sites. Even publishers who think of their audience as a Chrome-and-Safari crowd usually find a steady tail of Edge sessions in their analytics, particularly from office desktops and Windows laptops that never switched browsers. Ignoring Edge means leaving part of your ad-block exposure unmeasured.

Edge is built on Chromium, the same open-source engine that powers Chrome. For a publisher this is the single most useful fact about the browser: its extension model, its handling of ad blockers and its transition to Manifest V3 all follow Chromium's, not some Microsoft-specific path. The ad-blocking reality you already understand from Chrome is, with small additions, the ad-blocking reality on Edge.

There is one genuinely Edge-specific layer worth flagging up front, and it is easy to confuse with ad blocking: Edge ships its own built-in Tracking Prevention, on by default. We will come back to exactly what that does and does not block, because mistaking tracker prevention for a full ad blocker is a common way publishers misread their own numbers.

Because Edge runs on Chromium, it inherited the same Manifest V3 transition Google drove. Manifest V2 has been deprecated, and the blocking form of the webRequest API that classic blockers relied on is gone. In its place is declarativeNetRequest, where the extension registers a fixed set of rules ahead of time and the browser enforces them natively, below the page, rather than letting the extension decide request by request in JavaScript.

The practical consequence is the same one Chrome publishers already faced. Classic uBlock Origin, which depends on the Manifest V2 webRequest API, cannot run as an MV3 extension; on up-to-date Chromium its role passes to uBlock Origin Lite, usually written uBOL. uBOL is a different, quieter extension built around declarativeNetRequest, with Basic, Optimal and Complete permission modes that change how much it is allowed to do on a given site. On Edge you should expect uBOL, AdGuard's MV3 build and similar declarative blockers, not the old dynamic ones.

Edge users get their extensions from two places: Microsoft's own Edge Add-ons store and, with a setting enabled, the Chrome Web Store. Either way the blockers on offer are the Chromium-platform blockers, uBlock Origin Lite, AdGuard, and the rest, operating under the same MV3 constraints. The supply is shared, the platform is shared, and so the detection problem is shared. A detector that correctly handles Chrome MV3 and uBOL already handles Edge's extension blockers.

This is why we do not treat Edge as a separate browser to be detected from scratch. The hard part of detection on Edge is not Edge; it is MV3 and uBOL, which AntiAdBlock Core already covers as part of its Chromium support, retraining its heuristics daily against the major filter lists.

Edge ships a feature called Tracking Prevention, switched on by default, with three levels: Basic, Balanced and Strict. The default is Balanced. It is important to be precise about what this is: it blocks known trackers drawn from curated lists, which limits cross-site tracking and some analytics. It is a privacy feature, not a general-purpose ad blocker, and it does not set out to strip every display ad from a page the way uBlock Origin does.

The distinction has real consequences for your numbers. At Balanced, many ads still load normally because the blocked resources are trackers rather than ad creatives. At Strict, Edge blocks a wider set of trackers, and that can have side effects, some ads or site features that depend on a blocked tracker may break as collateral, even though breaking ads was not the goal. A publisher who sees occasional gaps in ad delivery on Edge should consider Strict Tracking Prevention as one possible cause, separate from any extension.

For detection this means you are dealing with two independent layers on Edge, and you should not conflate them. One layer is an extension-based content blocker like uBOL, which is the same problem as on Chrome. The other is the browser's own Tracking Prevention, which behaves differently, it is list-driven, level-dependent and tracker-focused. A detection engine that only thinks in terms of extension blockers will misread what is happening when Strict mode, rather than an add-on, is the thing interfering with delivery.

The oldest anti-adblock trick is DOM bait: create an element with a class like ad-banner, wait a moment, and check whether it was hidden. That signal was built for the Manifest V2 world, where the blocker did visible work in JavaScript inside the page. Under MV3 the blocking happens in the browser's network layer, so uBOL on Edge can drop an ad request without ever touching a bait element you planted in the DOM. The page simply sees a request that failed.

uBOL is also mode-dependent in a way a single probe cannot capture. In Basic mode it does network filtering through declarativeNetRequest but little cosmetic work; in Optimal and Complete it does more. The same extension can be nearly invisible on one site and aggressively cosmetic on another, depending only on the permission the user granted. A one-shot bait check produces a noisy, mode-dependent answer, and on uBOL it produces false negatives, the worst outcome, because revenue is lost while the script reports nothing.

Layer Edge's Tracking Prevention on top and the single-signal picture gets murkier still. A bait or probe that happens to look like a tracker can be blocked by Strict mode even when the visitor runs no extension at all, while genuine ad creatives load fine. Read in isolation, that one signal can suggest a blocker that is not there, or miss one that is. Reliable detection on Edge has to read several independent signals and let them vote, rather than trusting any single artefact.

The robust approach on Edge is the same ensemble approach that works on Chrome, because the underlying platform is the same. Instead of one bait element, you run many independent vectors and combine their verdicts. Behavioural signals survive MV3: when the browser blocks a known ad request natively, the failure behaves differently from a slow server or a genuine network error, and observing that across several probes is a signal a filter rule cannot simply erase.

A second strong signal comes from MV3 heuristics. declarativeNetRequest can do more than cancel a blocked request, and the way the extension handles it leaves its own traces. When a request that should have returned ad code behaves in a way a real ad server never would, that is itself evidence of a blocker, and a strong one for uBOL. No single vector is conclusive on its own, which is exactly why an ensemble that votes across many is the durable model.

AntiAdBlock Core uses a multi-signal ensemble engine with a stated detection precision of around 99.7%, and because Edge is Chromium it inherits that coverage directly, uBOL across its Basic, Optimal and Complete modes, plus the awareness that Strict Tracking Prevention is a separate layer. Installation is the same single async script, loaded in the head; it is free for the first 5,000 detections each month, so you can measure your real Edge exposure before deciding on any recovery flow.

From there the playbook mirrors any other platform: measure your baseline ad-block rate, including Edge sessions specifically, then track how many visitors allow the site once the notice is live. The point is not to treat Edge as exotic, but to make sure your detection is MV3-aware enough to see what Edge's Chromium blockers and its built-in tracker layer are actually doing.

Edge's Chromium base means the chrome-mv3-ad-blocking-publishers guide applies directly, Manifest V3 restrictions and declarativeNetRequest blockers behave identically on both. For implementation options once you have measured your exposure, the how to block adblock on your website guide covers the options and the steps.