Your autoplay is being refused, and the statistic about it is measuring something else

Muted autoplay is the only autoplay a first time visitor gets

Chrome states its policy as a list. Muted autoplay is always allowed. Autoplay with sound is allowed if the user has interacted with the domain, if the Media Engagement Index threshold has been crossed on desktop, or if the site is on the home screen on mobile or installed as a PWA. The Chromium project page adds one condition the blog leaves out, and it matters later: content that includes no audio at all is also allowed. Firefox 66's release notes are one sentence: Firefox now prevents websites from automatically playing sound.

Those three escapes read as generous and are not. Chrome counts a significant playback event only when consumption of the media is greater than seven seconds, audio is present and unmuted, the tab with the video is active, and the video is larger than 200 by 140 pixels. It publishes no threshold for the resulting score, so any article quoting you a Media Engagement Index number did not get it from Chrome. A visitor arriving cold from a search result has none of the three, and is exactly the person the hero video was made for.

Safari adds two requirements almost nobody counts. Apple's documentation says video elements including autoplay play automatically on macOS and iOS only if those elements also include the playsinline attribute, and that without it, videos must be in full-screen mode for playback on iPhone. Playback also stops if the element is not visible onscreen or is out of the viewport. In the June 2024 crawl, 7.35 per cent of mobile video elements compute to display none, and an element Safari cannot see is one it will not start.

Muted autoplay is not the fallback. For a visitor arriving cold, it is the only autoplay there is.

Only a play() call is told it was refused

The refusal has a name in one case only. Call play() yourself and both engines reject the promise: Chrome with a NotAllowedError DOMException when the autoplay permissions policy is disabled, and WebKit's iOS post equally plain that play() returns a promise, rejected if any of these conditions are not met. The autoplay attribute gets no such courtesy: it is ignored, and Safari's other refusal is a pause: playback pauses if the element gains an audio track, becomes unmuted without user interaction, or is no longer onscreen. A pause is not an error, so there is nothing to catch.

MDN states the consequence in one line: no specific event, or other notification, is triggered by autoplay success or failure. The one standard way to ask in advance is Navigator.getAutoplayPolicy, which the W3C Media Working Group's Autoplay Policy Detection draft, dated 4 September 2025, defines with three values, allowed, allowed-muted and disallowed. MDN's compatibility data records it as added in Firefox 112 and false for both Chrome and Safari, still experimental. In two of the three engines the page has to try, fail and recover.

Which makes Chrome's own instruction the most ignored sentence in the subject: do not ever assume a video will play, and do not show a pause button when the video is not actually playing. A hero video with a pause control drawn at build time asserts a state nobody checked.

A silent audio track is still an audio track, and Safari counts it

The rule that costs real money sits in WebKit's macOS policy note of 8 June 2017. Audio tracks that render silence are still audio tracks, it says, and their existence affects whether a video will auto-play at all; in these cases a video with silent audio tracks will not play, and the audio track should be removed or the muted attribute set on the element. That is a rendering decision, not a markup one, and it lands on anybody who mixes audio into an export: a file with a music bed under it carries an audio track by definition, silent stretches included.

Auto-play permission is granted per element, which is why playing clips back to back means changing the source of one element rather than creating several. A power saving feature prevents silent videos from auto-playing when hidden in a background tab or off-screen, on top of the inference engine that blocks media with sound on most websites. WebKit's summary of the lot: websites should assume any use of video or audio requires a user gesture click to play.

None of this is a browser vendor being awkward. The HTML Standard ships the pattern as its own worked example: an advertisement with controls, autoplay, loop and muted set together, annotated with the note that the user agent can pause the video if it is unmuted without a user interaction. The spec wrote the muted attribute into the example because that is the attribute the permission is granted against.

The 23 per cent is a share of attribute occurrences, not of video elements

The query behind figure 5.40 of the 2024 Web Almanac media chapter is published, and it divides one attribute's frequency by the summed frequency of every video attribute row it returns, partitioned by client. The results workbook gives the raw rows: on mobile, autoplay 389,697 occurrences out of 1,722,853, which is 22.62 per cent, and muted 131,116, which is 7.61 per cent. Rounded, 23 and 8. Those fourteen mobile rows sum to 1,722,853 exactly, so the denominator is every video attribute the crawler recorded in June 2024, which is why the two figures can sit next to each other and mean nothing about compliance.

The 2022 chapter ran the same query and described it correctly: autoplay accounts for 20 per cent, preload 16, width 12, and the prose called autoplay the most popular attribute. Accounts for. Two years later, on the identical measurement, the sentence became present on 23 per cent of video elements, and that is the wording now quoted back as a finding. Two cheap checks on it. The ten values in that figure description sum to 104 per cent, which no share of one population can do. Its preload figure of 16 per cent is the 2022 number: the 2024 workbook says 10.70 per cent, and the chapter's next sentence says preload's usage decreased six percentage points.

The workbook settles it in two columns. One tab counts video elements a row at a time and totals 2,003,977 of them in the mobile crawl, and a second derives 2,004,181 from a different query: a disagreement of 204 elements in two million. Against the 1,722,853 attribute occurrences the published query recorded, that is 0.86 attributes per video element. A video element carrying controls and a src already has two.

The honest figure is about one page in ten, and even that is a ceiling

The same workbook holds a query no figure in the chapter uses, and it measures what the popular sentence claims. Among the 1,061,712 mobile pages carrying at least one video element, 69.10 per cent have a video with an autoplay attribute, 69.74 per cent one with a muted attribute, and 62.06 per cent both somewhere on the page. Desktop: 70.75, 70.87 and 63.01. Subtract, and 7.04 points of pages with video ask for autoplay while carrying no muted attribute anywhere. That is 10.2 per cent of the pages that ask on mobile and 10.9 per cent on desktop, roughly 74,700 pages on mobile and 75,000 on desktop.

Both queries read the same field of the same crawl and cannot both be right. The published one reports 131,116 muted occurrences in the whole mobile crawl, while the second says 740,415 mobile pages carry a video with a muted attribute, and each contributes at least one occurrence. A factor of 5.65 in the wrong direction, and 1.88 on autoplay. The published query joins the array of attribute records into one space joined string and then reads a single attribute name out of it, which is enough to explain an undercount and not enough to prove one. The contradiction stands without it. Nothing gets 740,415 pages out of 131,116 occurrences.

One page in ten is a ceiling on the breakage, not an estimate of it. A file with no audio track needs no muted attribute to autoplay, in Chrome and Safari both. And a page level count cannot say whether the autoplay and the muted sit on one element.

The bigger hole is the one no crawl can see. The HTML Standard defines the muted content attribute as the default value for muting, reflected as defaultMuted, so an element muted with video.muted set to true in script satisfies both engines and never writes the attribute into the document. Nobody has measured how often authors do that.

The measured muted rate is a floor, not a census: a video muted in script is invisible to every markup crawl ever run.

What to do about it

1. Strip the audio track from anything meant to autoplay silently, and set the muted attribute anyway on the element that keeps one.
2. Add playsinline to every autoplaying video element, then load the page on an iPhone and watch it rather than trusting the markup.
3. Never quote an attribute rate from a crawl without reading its query. The Almanac publishes the SQL, and the denominator lives in the final SELECT.