How to Stop Video Ads From Playing in Chrome: 3 Levers (2026)

A pre-roll video ad starts playing with sound the second you open a streaming, news, or social page, with an ad blocker already on. Three levers stop it: mute the one site in Chrome’s Sound setting, block unmuted autoplay sitewide, or cut the ad’s network request at the source with a 195K-rule DNR blocklist. The last one keeps the video ad from loading when it arrives as its own network request.

You are mid-scroll on a site you visit every day, you click the video, and a pre-roll rolls in with the volume up. The scroll position you had built is gone under the player. The half-typed comment in the box is gone with it. The same re-interruption lands on every visit, and it compounds because you keep opening the same sites. The blocker you trust to catch this let it through.

Key takeaways

• Mute one site in Chrome’s built-in Sound setting to kill the sound on that domain. The video still loads and still plays, now silent, and it is a per-site, manual step.
• Chrome’s autoplay policy blocks unmuted autoplay by default, but high-engagement sites like YouTube earn an automatic exception, so the native Block Autoplay setting often does not touch their players. Muted autoplay is allowed by design.
• The request-layer fix stops a video ad that loads as its own network request, and a separate Video Ad Blocking feature strips ad data from YouTube and Twitch API responses. URL-matching rules in a 195K+ DNR blocklist miss ads a site bundles inside its own responses.

Option 1: Mute One Site in Chrome’s Sound Setting

This is the fastest stopgap when a single site keeps rolling a pre-roll with the volume up. Chrome’s built-in Sound setting ships with three defaults and a per-site exceptions list. Add the offending domain to the exceptions and switch that one entry to mute. The video ad on that site still loads and still plays, but it now plays silent.

Treat it as the fix for the one page that annoys you most, not a sitewide solution. It works one domain at a time, by hand, so noisy sites become menu dives.

Option 2: Turn On Stop Autoplay Sitewide

Two separate levers do this job, and they are not the same switch.

Chrome’s native autoplay policy blocks unmuted autoplay by default, but it backs off for any site whose Media Engagement Index is high enough. That index builds from repeated unmuted playbacks longer than seven seconds in the active tab, so high-engagement sites (e.g., YouTube) earn an automatic exception, and the native Block Autoplay setting often does not apply to their players. Muted autoplay is allowed by design, per the WHATWG HTML spec, so a muted ad still plays even with the policy on.

SuperchargePerformance has its own Stop Autoplay feature, separate from Chrome’s policy. It has two levels. Level 1 (Allow Common) lets major video and conferencing sites keep playing, and Level 2 (Block All) blocks autoplay everywhere. The feature is off by default, and it is a separate lever from the browser’s own setting, so you can run them together. It stops an ad from autoplaying, which is the symptom you feel.

Option 3: Block the Ad’s Network Request at the Source

This layer removes the video instead of muting or pausing it, because it stops the ad from loading in the first place. SuperchargePerformance does it with declarativeNetRequest (DNR) rules, which operate at the network-request layer rather than inside the page. The extension ships 195K+ DNR rules, and all four blocking tiers (Off through High) are available without PRO.

The DNR model also sets the limit of this layer. A declarativeNetRequest only applies to requests that reach the network stack, and may not include responses that go through a service worker’s onfetch handler (Chrome DNR reference, developer.chrome.com, retrieved 2026-10-20). Because the rules match on requests, a blocklist has to be big enough to cover the ad endpoints that do reach the network stack. The limits that let a 195K-rule list fit are: up to 100 static rulesets with 50 enabled at once, a guaranteed minimum of 30,000 static rules, 5,000 unsafe dynamic rules and 30,000 safe dynamic rules (from Chrome 121), and 1,000 regex rules per rule type, each under 2 KB compiled.

Why Video Ads Slip Past a Normal Ad Blocker

A URL-matching ad rule only fires when a request reaches the network stack. Two things keep video ads from ever presenting a matching URL.

The first is an in-page or bundled response. An ad that a site injects into its own DOM, or serves inside the site’s own API response, is never a separate ad-server URL the rule can grab. YouTube is the canonical case. Its video ads are bundled inside YouTube’s own API responses, so a URL-matching rule never sees the ad payload (YouTube ads still showing with an ad blocker). SuperchargePerformance covers that case with a separate Video Ad Blocking feature, on by default, that strips ad data from YouTube and Twitch API responses.

The second is a dead extension. Chrome disabled all Manifest V2 extensions in Chrome 138 (July 2025, roughly 15 months before this article’s October 2026 publication) and removed the last re-enable flags by Chrome 150 and 151. On the current stable (156), only Manifest V3 blockers that use DNR actually run. If your “ad blocker” is an older MV2 build, it is doing nothing at all, and every video ad plays as if you had no protection.

If One Site Still Plays Video Ads

If a specific site’s video ads still play, do not turn the blocker off: confirm the blocking tier is set above Off (High is the default and the strongest), since ads bundled in a site’s own response escape URL rules. If a site breaks instead, add only that site to the per-site Whitelist Manager so it loads normally while blocking stays on everywhere else. The override is per-hostname, so the rest of the web keeps its protection.

If instead the whole thing just stopped working, the cause is usually a dead Manifest V2 extension, not a broken rule. On current Chrome only MV3/DNR blockers run, so an old blocker is silently doing nothing. The troubleshooting article on ads that still show walks that specific case, and the autoplay guide covers the sitewide setting in more depth.

Keep the request-layer blocking on sitewide and whitelist the one site that breaks, rather than trading a single broken page for an unprotected browser.