IMA SDK ad blocking, explained

What the IMA SDK actually is

The Interactive Media Ads (IMA) SDK is Google's client-side library for video advertising. A website that wants to monetize a video does not usually build its own ad player: it loads imasdk.googleapis.com/js/sdkloader/ima3.js (or the dynamic variant ima3_dai.js), initializes an AdDisplayContainer, and hands the SDK an ad tag URL. The SDK then fetches a VAST response, renders the ad inside the player, tracks impressions and quartiles, and finally hands control back to the publisher's content.

Because it is one shared script served from one domain, the IMA SDK is the single most leveraged chokepoint in web video advertising: neutralize it once and every player built on it stops delivering ads.

The life cycle of an ad request

When a viewer presses play, the player typically runs this sequence:

1. The page loads ima3.js from Google's servers.
2. The player creates an ads loader and requests ads with an ad tag pointing at an ad server.
3. The SDK fetches the ad (usually a VAST/VMAP document via DoubleClick), parses it, and renders the ad media into a container over the video.
4. Tracking pixels fire; the player waits.
5. When the ad finishes (or errors out), the SDK fires CONTENT_RESUME_REQUESTED, and the player resumes the actual video.

That last event is the key: the player is written to wait for it. Whoever controls the SDK controls when content resumes.

Why simply blocking the SDK breaks players

The crude approach is to block imasdk.googleapis.com at network level and call it a day. The problem: many players interpret a failed or missing SDK as a fatal error and refuse to start the video at all, showing a loading spinner or an "adblock detected" wall instead of the content.

This is why classic network-level blockers are weak against video ads: they can stop the ad request, but they cannot answer the player's question "can I resume now?". Only something standing in for the SDK can.

Neutralization by substitution: the stub approach

AdOff takes a different route: instead of blocking the SDK, it replaces it. A stub that mimics the IMA SDK's public API is swapped in, so the player still "sees" a working SDK — one that behaves as if every ad break were empty.

When the player calls adsManager.start(), the stub immediately emits CONTENT_RESUME_REQUESTED. The player resumes the content instantly. No ad is fetched, no ad is rendered, and the player never enters an error state because it never notices anything missing.

Two delivery channels for the same stub

AdOff ships the same stub through two channels, because different sites load the SDK differently:

• In-page injection. On sites that are not excluded, a main-world script defines window.google.ima before the player initializes, so the bundled or externally loaded SDK is superseded by the stub.
• Network redirect. For a set of 42 European broadcaster domains, declarativeNetRequest rules redirect the request for ima3.js and ima3_dai.js to the stub file bundled inside the extension. The page loads what it thinks is Google's SDK and gets AdOff's instead.

Both channels converge on the same outcome: the player gets a responsive SDK, the viewer gets content.

Where this approach does and does not reach

The stub neutralizes client-side IMA-based advertising. It does not affect server-side ad insertion (SSAI), where ads are stitched into the video stream itself before delivery — there is no SDK call to intercept. Premium subscription services using their own ad pipelines are deliberately excluded so their players keep working.

The main video platform also gets a dedicated pipeline on top: ad scheduling is stripped from the player's response before the page reads it, and anything that slips through is fast-forwarded.

Why this matters for the future of ad blocking

Ad platforms keep shifting weight toward client-side SDKs precisely because naive blockers struggle with them. An approach that answers the player instead of starving it is robust: it does not depend on enumerating every ad URL, only on the SDK's own contract that content must resume.

AdOff is a free, account-less Manifest V3 extension for Chrome, Firefox, Safari, Edge and Opera, and its video neutralization layer is included for everyone.

Frequently asked questions

Is blocking the IMA SDK the same as replacing it?

No. Blocking it at network level often prevents the video from playing, because players wait for the SDK to signal that content can resume. Replacing it with a stub keeps the player fully functional while ensuring no ads are ever requested.

What happens when the stub receives an ad request?

The stub exposes the same API surface players expect. When asked to start ads, it immediately fires the content-resume event, so playback continues without any ad being fetched or rendered.

Does an IMA stub work against server-side ad insertion?

No. With SSAI the ads are stitched into the video stream on the server before delivery, so there is no client-side SDK call to intercept. Server-side insertion requires different countermeasures and is outside what a browser extension can address.

Which browsers can run this kind of extension?

AdOff is built on Manifest V3 and works on Chrome, Firefox, Safari, Edge and Opera. The IMA neutralization layer is included in the free version, with no account or registration required.

Can a site detect that the SDK has been replaced?

That is the purpose of the stealth layer: bait spoofing and fetch/XHR interception make the environment look ordinary to anti-adblock scripts. No method is permanent, since platforms change their detection frequently.

More on this: Streaming ad blocking: the complete guide, Pre-roll, mid-roll, post-roll: video ad formats explained, How AdOff works, layer by layer.