Quick answer: Browsers block audio until a user gesture. Add a “Tap to Start” screen and trigger your first Play action from that tap — the audio context unlocks then.

A web game tries to play music on start of layout. It’s silent. The browser’s autoplay policy blocked the audio context until the player interacts.

Why Browsers Block It

To stop ad pages from blaring sound, browsers suspend the Web Audio context until the user does something — a click, tap, or key press. Construct’s Audio object can’t play before that.

Tap-to-Start Pattern

On start of layout:
    → Show "Tap to Start" overlay

On Touch / On click anywhere:
    → Audio: Play Music (looping)
    → Hide overlay
    → Start game

The first user input unlocks the audio context. Trigger your music from that same event.

Don't Rely on “Unlock” Alone

Some flows call a silent “unlock” play on first input, then start real audio later. That works, but a visible “Tap to Start” is clearer UX and guarantees the gesture happened.

Resume After Tab Switch

The context can also suspend when the tab is backgrounded. On the “On resumed” / visibility-change event, the Audio object usually resumes automatically — but test it, and re-trigger ambient loops if needed.

Verifying

Load the game in a fresh browser tab. Audio is silent until “Tap to Start”. After the tap, music and SFX play normally for the rest of the session.

“Browser autoplay policy is non-negotiable. Gate your first Play behind a real user gesture.”

Make the start screen do double duty — it’s also where you preload assets and show your logo. Players expect a tap-to-start on web.