Mobile (and most desktop) browsers suspend audio until the user has interacted with the page – a click, tap or key press. This is a built-in autoplay policy, not a bug. Start or resume your AudioContext inside that first input event, or start audio muted until unmuted.
At a glance
| Fact | Value | Source |
|---|---|---|
| Autoplay blocked unless user has interacted | click, tap, key press | developer.mozilla.org |
| AudioContext resumes after user interaction + start() | both conditions needed | developer.chrome.com |
| Web Audio API browser support | all modern browsers except Opera Mini | developer.mozilla.org |
Mobile browsers suspend audio because they treat any sound started without user action as unwanted noise or unwanted data use, so they hold playback until the visitor has actually interacted with the page. As MDN puts it, media “will be allowed to autoplay only if” the audio is muted, the user has interacted with the site by clicking, tapping or pressing a key, the site is allowlisted, or an iframe was granted the autoplay permissions policy (MDN Autoplay guide). Playgama MCP lets an agent upload a build and publish a sandbox link to test audio behaviour on a phone browser without leaving your editor.
For Web Audio specifically, Chrome explains the mechanics: an AudioContext starts suspended and only resumes when two things are both true – the user has interacted with the page, and a source node’s start() has been called. Calling resume() inside a click or touch handler is the standard fix (Chrome autoplay policy).
Older MDN guidance on games audio adds a mobile-specific note: many mobile browsers ignore autoplay requests entirely, may disable programmatic volume control, and disable buffering until playback has started, likely to limit unexpected mobile data use.
What to check yourself
- Wrap your first sound/music start in a tap or click handler, then call
resume()on the AudioContext. - Ship a muted default and a visible unmute/sound button rather than relying on autoplay.
- Test inside an iframe if your game will run on a portal – itch.io warns that “audio may be muted on some browsers when using auto-start.”
Sources
- Audio for Web games – MDN
- Web Audio, Autoplay Policy and Games – Chrome for Developers
- Autoplay guide for media and Web Audio APIs – MDN
- Uploading HTML5 games – itch.io
- Playgama MCP
Related questions
Does muting audio by default avoid the autoplay block?
Yes. MDN lists muted or zero-volume playback as one of the conditions browsers allow to autoplay; pair it with a visible unmute button tied to a click or tap.
Will resume() work if called before any user interaction?
No. Chrome’s autoplay policy requires the user to have interacted with the page first; call resume() inside that interaction’s event handler, not on page load.
Does this affect desktop browsers too?
Yes, though behaviour varies. MDN’s cross-browser audio guide notes that browsers ‘have policies that will block autoplay entirely in many situations’ on both desktop and mobile.
Last updated: 30 September 2026