Autoplay rules in browsers
Chrome, Safari and Firefox all block autoplay with sound until a person has interacted. What each one allows, how the rules reach an iframe, and how to design around them.
Modern browsers allow autoplay only when the video is muted, or when the viewer has already clicked on the site. Autoplay with sound and no prior click is blocked. Embed with ?autoplay=1&muted=1, keep allow="autoplay" on the iframe, and let the viewer turn sound on.
The rule is short and the exceptions are long. A browser will start a video by itself only if it is silent, or if it has reason to believe the person wants it. The rest of autoplay policy defines "reason to believe", and each browser defines it a little differently. That is why the same embed plays on your machine and stays frozen on a colleague's. On a phone, it may show a poster with a mute icon.
This guide sets out what Chrome, Safari and Firefox actually do. It shows how those choices pass through an iframe to an embedded player, and how to build pages that behave the same everywhere. It ends with the accessibility rules for anything that moves or makes noise without being asked. Those rules limit the design more than the browsers do.
Why the policies exist
Autoplay with sound was the web's most complained-about behaviour for a decade. A page opened in a background tab starts talking. An advert shouts over a meeting. A hotel wifi bill grows because a hero video looped all night. Browsers responded between 2017 and 2019 by tying audible playback to evidence of intent. Safari 11 introduced per-site autoplay settings on macOS in 2017; Chrome 66 shipped its policy in April 2018; Firefox 66 blocked audible autoplay by default in March 2019. The policies differ in detail but agree on two big points. Muted video may start on its own. Video with sound may not, until the person has done something.
What each browser allows
A summary of the documented policies. Users can loosen or tighten all of them in settings.
| Browser | Muted autoplay | Audible autoplay | Notes |
|---|---|---|---|
| Chrome and Edge | Always allowed | After a click or tap on the site, or with a high engagement score for that site | Iframes need allow="autoplay" to inherit permission |
| Safari (macOS) | Allowed by default | Blocked by default; per-site setting | Users can choose Allow All, Stop Media with Sound, or Never Auto-Play |
| Safari (iOS) | Allowed with playsinline | Blocked until a tap | Low Power Mode can prevent autoplay entirely |
| Firefox | Allowed by default | Blocked by default; per-site setting | Users can also block muted autoplay |
How Chrome decides you want it
Chrome's policy, documented on the Chrome developers blog, allows audible autoplay in three cases. First, the person has clicked or tapped on the domain during that visit. Second, the site's Media Engagement Index is high enough. That means the person has often played video with sound on that site before. Third, on mobile, the person has added the site to their home screen.
The engagement index is why a video-heavy site you use daily autoplays for you and not for a first-time visitor. It is also why testing autoplay in your own browser tells you almost nothing about a stranger's experience. Test in a fresh profile or a private window.
For embedded players there is one more rule. A cross-origin iframe does not inherit the parent page's permission unless the parent delegates it with allow="autoplay". The VideoBB embed includes that token by default. Delete it and the player cannot autoplay even after the viewer has clicked around your page.
Muted autoplay is always allowed.
Chrome autoplay policy, developer.chrome.com
Mobile, low power and data saver
Phones add conditions. iOS Safari plays inline only when the video element carries playsinline; otherwise it opens the system player, which never autoplays. VideoBB's player sets this for you. When the device is in Low Power Mode, Safari may decline to start any video until the person taps it, regardless of mute. Android browsers with a data-saver setting enabled can behave the same way, and Chrome exposes the preference to sites as the Save-Data hint. The practical consequence is that a design must be complete without autoplay: the poster, the play button and the surrounding copy have to make sense on their own.
Embed for autoplay on VideoBB
The sequence that works across browsers.
Add both parameters
Use
?autoplay=1&muted=1on the embed src. Autoplay without mute is refused for most first-time visitors.Keep the allow attribute
allow="autoplay; fullscreen; picture-in-picture"delegates the permission to the frame. Removing it silently disables autoplay.Do not lazy-load an autoplaying hero
loading="lazy"defers the frame; for a player at the top of the page remove it so playback starts as soon as the page paints.Offer sound as an action
The player's controls let the viewer unmute. If sound is essential, prefer a poster and a play button over autoplay, so the first play is the viewer's click.
Test in a private window and on a phone
Your own browser has an engagement history with your site. A private window and a device that has never visited it show what new viewers get.
For developers: the play() promise
If you control a video element directly rather than through an embed, play() returns a promise. When the browser refuses, the promise rejects with a NotAllowedError. The correct response is to fall back rather than to retry. Set muted = true and call play() again, or show the poster and a play control. Never assume playback started because you asked for it. MDN's autoplay guide walks through the pattern and the older behaviour of browsers that ignore the promise. The same reasoning applies to the Web Audio API, where an AudioContext created before any interaction starts suspended.
Silent autoplay or click-to-play?
Silent autoplay
- Works everywhere as a preview or ambient visual
- Good for product loops, backgrounds and short demonstrations
- Must be pausable and should respect reduced-motion
- Costs bandwidth for viewers who never wanted it
Click-to-play
- Sound is guaranteed once playing, because the click is the gesture
- Right for anything with speech, music or a narrative
- No policy differences between browsers to worry about
- Needs a strong poster frame to earn the click
Patterns that behave the same in every browser
- A muted, looping clip with
?autoplay=1&muted=1&loop=1as a visual header, with a visible pause control. Keep the loop to a few seconds: cut it with the free trim tool and shrink it with the video compressor before you upload it. - A poster with a play button for talks, tutorials and anything with dialogue; sound follows the click.
- A muted autoplay preview that switches to a full, audible video when clicked, with the click also acting as the browser's user gesture.
- A deep link with
?t=for reference pages, where the viewer's click on the link into the page is not enough on its own, so the video waits for play.
What autoplay is for
Used well, silent autoplay is a preview: it shows a viewer what they would get, and the click confirms interest. Used badly, it is a way of making a page feel alive at the cost of the viewer's attention and data. The features guide covers what makes the click worth it once it comes, and the analytics guide explains why autoplayed views distort watch-time figures. For sizing a looping header clip, see responsive video embeds. The embed guide has the full parameter reference.
Frequently asked questions
Why does my embed autoplay with sound for me but not for visitors?
Chrome keeps a Media Engagement Index for each site you use, and a site where you frequently play video with sound earns audible autoplay for you. Visitors who have never interacted with your site do not have that history, so they get the default: muted or nothing. Test in a private window to see what a first-time visitor sees.
Can I get around the block with a script that clicks play?
No. Browsers count only real user gestures such as a click, tap or key press, and they ignore synthetic events dispatched by scripts. Attempts to fake a gesture are treated as no gesture at all. The reliable path is muted autoplay for previews and a genuine click for sound, which is also what accessibility guidelines expect.
Does autoplay work when the video is set to loop?
Yes, under the same rules. A muted, looping embed with autoplay=1, muted=1 and loop=1 starts silently and repeats in every current browser. Provide a way to pause it. Under WCAG 2.2.2, looping motion that runs longer than five seconds must be stoppable. Viewers with reduced-motion preferences may not want it at all.
Will autoplay use viewers' mobile data?
Yes. An autoplaying embed streams from the moment it starts, and adaptive streaming will raise the quality as bandwidth allows. Keep autoplay to short clips, avoid autoplaying more than one video on a page, and consider click-to-play on pages where most traffic is mobile. Some browsers suppress autoplay when a data-saver or low-power setting is on.
Sources
- MDN: Autoplay guide for media and Web Audio APIs — The play() promise, NotAllowedError and feature-policy delegation.
- Chrome Developers: Autoplay policy in Chrome — Chrome's rules, including muted autoplay, user interaction and iframe delegation.
- WebKit: Auto-Play Policy Changes for macOS — Safari's per-site autoplay behaviour.
- Mozilla Support: Allow or block media autoplay in Firefox — Firefox's default and per-site settings.
- W3C: Understanding Success Criterion 1.4.2 Audio Control — The accessibility requirement for automatically playing audio.
Related guides
How to embed a video on a website
Copy one iframe, understand the six attributes it carries, and add the query parameters that control autoplay, mute, start time and looping.
Creator analytics: metrics that matter
Views, watch time, likes and daily charts each answer one question. How to read them in the Creator Studio, how to compare videos fairly, and a fifteen-minute weekly review.
Video player features that matter
Adaptive quality, fast seeking, captions, keyboard control and picture-in-picture do more for viewers than any skin. Here is what to look for and why.