An HTML `<video autoplay>` silently refuses to start in Chrome and Safari. Explain the browser autoplay policy and which attributes make autoplay actually work.

## The rule in one line A browser will not let a page start making noise by itself. Autoplay is permitted only when playback is silent, or when the user has done something that counts as permission. ## Why the policy exists Before the policy, any page could open with a video ad blaring, and the user's only recourse was to hunt for the tab. Browsers responded by making audible playback a privilege: it must be requested by a user gesture (a click, a tap, a key press) or the media must be muted. This is a browser *policy*, not a line in the HTML specification, which is why the exact thresholds differ between engines — but the muted-or-gesture core is universal, so write markup that satisfies it everywhere rather than probing for the current rules. Some engines soften the rule with a per-site allowance: Chrome tracks how much you have historically watched media on a site (its Media Engagement Index) and may permit audible autoplay there, and Safari lets the user grant a per-site "Allow All Auto-Play" permission. You cannot rely on either — the same page will behave differently for a first-time visitor. ## The markup that actually works ```html <video src="loop.mp4" autoplay muted loop playsinline poster="first-frame.jpg" width="1280" height="720"></video> ``` - **`autoplay`** asks the browser to start as soon as enough data is buffered. On its own it is only a request. - **`muted`** is what makes the request grantable. It is a boolean content attribute; it must be present in the markup (or the corresponding property set before playback is attempted), not toggled afterwards. - **`playsinline`** matters on iPhone. Historically iOS Safari forced any `<video>` into the native fullscreen player when it started; `playsinline` requests inline playback. Without it a "background video" hijacks the screen on the exact devices where that is most disruptive. - **`loop`** is unrelated to the policy but almost always wanted for decorative background video. ## What refusal looks like Nothing dramatic happens. The element stays on its `poster` frame, no error is rendered, and nothing appears in the page. If playback is started from script, `play()` returns a promise that rejects with a `NotAllowedError`, which is the only reliable signal that the policy — rather than a network or codec problem — is the cause. That distinction matters when debugging: a codec failure fires `error` events, a policy refusal does not. ## The trap: unmuting later A popular pattern is to autoplay muted and then offer a "sound on" toggle. That is fine *when the toggle is a real click*. What fails is unmuting on a timer, on scroll, or on page load, because the browser still considers the resulting audible playback ungesture-backed and may pause the element outright. Keep the unmute bound to a genuine user action, and make that action a real `<button>` so keyboard users can reach it. ## Audio is not exempt `<audio autoplay>` is subject to the same policy, and `muted` autoplay of an audio element is pointless, so in practice audio always needs a user gesture. There is no `poster` and no `playsinline` on `<audio>` — those are `<video>` attributes. ## Autoplay interacts with the download hints Writing `preload="none"` next to `autoplay` is contradictory: the browser needs the media data to start playing, so the autoplay request wins and the preload hint is effectively ignored. Similarly, `controls` has no bearing on the policy — showing a control bar does not grant permission, and a muted autoplaying background video usually omits `controls` entirely. ## Practical checklist 1. Decorative/background video: `autoplay muted loop playsinline`, plus a `poster` so the first paint is not blank. 2. Content the user came to watch: no `autoplay` at all — show `controls` and let them press play. This also avoids burning mobile data. 3. Any "start with sound" requirement: put it behind a click, and design for the case where the click never comes. 4. Never assume autoplay succeeded. Whatever the page looks like on the frozen poster frame is what a share of your users will see.