Browser audio troubleshooting guide

Browser audio is not working, but other apps have sound: what to test next

A controlled way to narrow down browser-only audio problems without changing every sound setting at once.

By WaveLocus Editorial · Published September 2026 · Materially reviewed September 2026

When a game, music app, or system sound works but websites are silent, the problem may be limited to one site, one browser, one output choice, or one part of the system audio path. Do not start by resetting everything. First establish exactly where sound still works, then make one controlled comparison.

Separate a site problem from a browser problem

Open a second site that you know normally plays audio, then try the same page in the same browser. If one site is silent and another is not, you have evidence that the browser can still reach an output. Check that site's own mute control and permissions before changing the operating system. If every sound-producing site is silent in one browser, move to a known browser reference.

Run the WaveLocus audio test or the left/right audio test in the affected browser. These references do not rely on a video player, a streaming account, or a site-specific player setting. Write down whether the test is silent, plays through the wrong output, or plays normally.

Check the output path before reinstalling anything

Make sure the intended headphones, speakers, monitor, or interface is the active output. A connected Bluetooth device, HDMI display, USB interface, or dock can become the selected destination even when you are listening elsewhere. Keep the endpoint fixed while you make this check.

On Windows, Microsoft recommends checking the selected output, the Volume mixer, device mute state, disabled-device state, and audio enhancements when investigating sound problems. Follow the current steps in Microsoft's sound troubleshooting guide, because the labels can change between Windows releases. Do not assume that a browser is at fault simply because another app works.

Check the page before changing the computer

Some pages have their own player mute, volume, autoplay, or media-selection controls. Check those controls on the one affected page first. If a page has a visible error or says that playback is blocked, record the message rather than treating it as a general audio failure. A working WaveLocus reference and a silent video player point to a different next step than a browser that cannot play either reference.

Also note whether the affected browser is managed by a workplace, school, or family administrator. Extensions, content controls, remote-desktop sessions, and device policies can change how a browser behaves. Do not disable security software or remove management controls merely to make a test pass. The useful comparison is a normal, permitted test in the same path, followed by the smallest safe change that can explain the difference. If that change is unavailable to you, record the restriction as evidence rather than guessing around it.

Use one change at a time

Hold the hardware path still. Leave the same headphones or speakers connected. Do not switch cables, outputs, and browser settings together.
Test the affected browser. Run the same WaveLocus reference and record the outcome.
Test a second browser. Use the same endpoint and the same reference. A difference is useful evidence, but it does not by itself prove a browser defect. System routing, extensions, profiles, or permissions may still differ.
Check the system mixer and output. Confirm the browser application is not muted or assigned to an unexpected output. Re-run the same reference without changing any other variable.
Record what changed. If only one browser remains silent after the output check, note its version, extensions or managed-workplace restrictions, and the exact successful comparison.

What the result can tell you

Controlled resultBest supported interpretationStill unknown

One site is silent, but the WaveLocus reference and another site playThe browser and current output can play audio.Why that particular site is silent.

Every site and the reference are silent in one browser onlyThe issue is consistent with that browser's path, profile, or settings.Whether the browser itself, an extension, a policy, or the system route is responsible.

The reference plays in a second browser using the same outputThe endpoint and basic output path can work in that comparison.Whether an affected browser setting or a transient condition caused the first result.

Keep microphone issues separate

A page can have working playback while microphone capture fails, or the reverse. Microphone access is protected by browser permission and normally requires a secure HTTPS context. The MDN getUserMedia documentation explains that user permission and browser, operating-system, or hardware errors can all affect capture. Test it separately with the WaveLocus microphone test; do not treat a microphone failure as proof that browser playback is broken.

When the simple comparison is not enough

If sound cuts out during calls, use the headset workflow to compare microphone activity with stereo output. If audio is present but crackles, drops out, or feels delayed, record those observations separately. A silence problem, a routing problem, and a latency problem have different next tests. Combining them into one vague description usually makes troubleshooting slower.

Next step

Once you have one working and one failing comparison, open guided diagnosis. Record the source device, connection, endpoint, and the one variable you changed. The useful outcome is a narrow statement such as “the same headphones play the browser reference in Browser B but not Browser A.” That is much easier to investigate than “web audio does not work.”

Sources and method

This guide uses controlled local browser references and does not upload audio. For current Windows output and mixer checks, see Microsoft Support. For microphone permission and secure-context behaviour, see MDN's getUserMedia reference.