Why your HTML5 game has no sound on mobile

In brief

• Diagnose the failure before replacing music files or rewriting the game's audio system.
• Give the player a clear way to enable sound, and handle a failed playback attempt visibly.
• Test first load, return from another app, and the embedded version separately.

Identify the failure before editing the source

Start with one affected phone and one reproducible action. Note the browser version, game URL, mute setting and selected audio output. Check whether the sound file request succeeds, then inspect the playback error. Keep those as separate observations.

Browser autoplay rules can block script-started audio before the player interacts with the page. A silent first visit is therefore not, by itself, evidence that the purchased source is broken. See MDN's autoplay guide.

For HTML media, the promise returned by play() resolves when playback has started. A blocked autoplay attempt can reject with NotAllowedError. NotSupportedError can indicate an unsupported media format. Those outcomes call for different investigations: permission handling versus the media source. MDN documents these results.

Connect sound to an intentional tap

Offer a clearly labelled Enable sound button or an explicit sound choice on the start screen. Keep a mute control available afterwards.

For Web Audio suspended by Chrome's autoplay policy, call resume() on the audio context after user interaction. Chrome's game-audio guidance demonstrates doing this from a button click. Use the context that actually belongs to the game; do not add a second audio system without first tracing the existing one.

If the project uses a framework, find its audio initialization and sound-control functions before asking a coding assistant to patch them. Request a small change that preserves the existing mute preference and reports success or failure. For HTML media, update the control after the playback promise settles, not simply after the button was pressed.

Test the return-to-game path

On iOS Safari, leaving the page can put its audio context into an interrupted state that needs resuming. MDN's state reference describes this separately from normal playback.

Test switching apps, locking the screen and returning to the game. Record the context state before and after the interruption. If sound remains unavailable, offer a deliberate retry rather than silently claiming that it is playing. Preserve a player's choice to stay muted; returning to the tab should not be treated as permission to override it.

Check the embedded game and hand off a focused fix

An autoplay Permissions Policy can disable autoplay for a document and its nested frames. Compare the direct game URL with the version inside the host website, then review the host's policy and iframe permissions where supported. MDN explains this additional policy layer; it is not a universal substitute for player interaction.

Give your developer or coding assistant the failing URL, device and browser, reproduction steps, exact error, and relevant audio handler. Ask for the smallest fix plus tests for first tap, mute, repeated taps and return from background. Do not accept a desktop-only demonstration as the mobile acceptance test.

For slow loading or animation instead of silence, use the separate mobile HTML5 performance checklist.