DeviceBenchFree online sound test
Sound test that shows you the audio really is playing
Press the button and a three-note reference clip loops through a meter that sits in the signal path on its way to your speakers, so a moving trace is proof the audio engine produced sound. That splits the problem in two: a flat line means the page never played, while a full trace over a silent room puts the fault after the browser — the mixer, the default output device, the cable or the driver. What the meter cannot do is hear the room, so the panel beside it reports the engine state, the output sample rate and how many outputs this browser will admit to, and the numbered list underneath covers the rest.
- 100% free
- No signup
- One button
- Live waveform
- 7-step checklist
Nothing is playing yet. The engine stays closed until the button is pressed — that is the autoplay rule, and it is the first thing on the list below.
Not looked at yet — press Play.
Still nothing? Work down this list
- 1. The tab has not been clicked yet
Browsers refuse to open an audio output until the visitor has interacted with the page, and a page that autoplays gets a suspended engine and no error. The engine state below says which of the two you are looking at.
- 2. System volume, and the hardware mute key
The keyboard mute key and the OS slider are separate from everything a page can see. A monitor with its own on-screen menu has a third volume behind that, and it is the one people forget.
- 3. The per-app slider
Windows keeps a level for each program in Volume Mixer, and a browser muted there stays muted through reboots. macOS has no per-app mixer, but it does keep a level per output device, so switching back to a device you turned down last month restores the level with it.
- 4. The tab itself is muted
Right-click the tab strip: Chrome, Edge and Firefox all offer Mute site, it survives navigation, and the only sign is a small crossed-out speaker in the tab. Firefox additionally blocks audio on pages you have never interacted with.
- 5. Sound is going somewhere else
The default output moves on its own when a device appears. An HDMI monitor with no speakers, a docking station and a TV all present themselves as outputs, and a machine that plugged one in five minutes ago is playing perfectly into a device with nothing attached.
- 6. Bluetooth is in the wrong profile
A wireless headset exposes two: high quality stereo, and the narrow-band one used when an app has the microphone open. A meeting client left running holds the second, and the switch back does not always happen when the call ends.
- 7. The output device is muted at the driver
An output can be muted individually in the Windows sound panel or with a physical inline switch on a headset cable, which is not the same control as the system volume and does not move when you press the keyboard key.
The meter is watching the page’s own output, not the room. It cannot hear whether a speaker actually moved, so a full trace with a silent room narrows the fault to everything after the browser: the mixer, the cable, the amplifier and the driver, in that order.
How to test whether sound is coming out
Three steps, and the first one exists because the browser is deliberately holding your audio.
Press the button once, because the browser is waiting for exactly that
An audio engine opened without a click stays suspended, produces silence and reports no error, which is why so many people arrive here convinced their speakers died. The engine state next to the meter tells you which state you are in: suspended before the press, running after it. If it stays suspended after a real click, the tab has been muted or the site has been blocked from playing audio.
Watch the trace before you decide the machine is silent
The clip is three notes played in turn and then together, so the line jumps in a pattern you can follow rather than rolling past as a featureless sine. A trace that moves means the browser handed real samples to the operating system. A flat line with the engine running means the page failed, which is a completely different fault from a working page playing into the wrong device.
If the meter moves and the room does not, walk the numbered list
The list underneath is ordered by how often each cause turns out to be the answer, not by how technical it is. Half of the cases end at the fifth rung: an HDMI monitor, a dock or a television quietly became the default output when it was plugged in, and the machine has been playing perfectly into a device with no speakers attached ever since.
Technical specifications
| What it can and cannot observe | The signal leaving the page, measured on the way to the speakers. Whether a driver physically moved is invisible to a browser |
|---|---|
| Reference clip | 3 seconds on a loop: 440 Hz, 554.37 Hz and 659.25 Hz played in turn, then all three together |
| Meter | AnalyserNode over a 2,048-sample window, redrawn every animation frame and republished about eleven times a second |
| Level ceiling | Half of full scale at the top of the slider; the 60% default is about -10.5 dBFS |
| Fade at each edge | 15 ms, which is what stops the loop point from clicking on its own |
| Output devices | Counted through enumerateDevices(); names appear only after a microphone has been granted once, and Firefox and Safari never list outputs at all |
| Troubleshooting list | 7 rungs, ordered by how often each one turns out to be the cause |
| Data kept | None — the clip is synthesized in the tab on every press and nothing is recorded |
Frequently asked questions
I pressed Play and absolutely nothing happened. Where does that start?
It starts with the autoplay policy, and the engine state on the page tells you within a second whether that is what you are looking at. Since 2018 browsers refuse to start an audio context until the visitor has interacted with the page, and a context created too early comes back suspended rather than throwing an error. A second press after the page has been clicked once is usually enough. If it stays suspended, the tab has been muted from the tab strip or the site sits on the browser's blocked-for-audio list.
The waveform is moving but I still cannot hear anything. What does that rule out?
It rules out the browser, the page and the codec, which is most of what people suspect first. Samples reached the audio engine and the engine handed them onward, so everything still in question sits after the browser: the operating system mixer, whichever device is currently the default output, the physical connection and the speaker itself. That is exactly the order the numbered list works through.
Why did my sound move to the monitor on its own?
Because plugging in an HDMI or DisplayPort cable adds an audio output, and both Windows and macOS will make a newly attached device the default. A monitor without speakers still advertises an audio endpoint, so the machine keeps playing into it happily and reports no fault anywhere. The same thing happens with docking stations, USB hubs with audio and televisions, and it happens again every time the cable is reconnected.
Sound works everywhere except in my browser. Is that possible?
Yes, and there are two separate controls that do it. Windows keeps an independent volume for every program in Volume Mixer, and a browser turned down there stays down through restarts while every other application plays normally. The second is per-tab: right-clicking a tab offers Mute site in Chrome, Edge and Firefox, it survives navigation to other pages on the same origin, and the only visible sign is a small crossed-out speaker on the tab itself.
Why can the page not tell me which speaker it is using?
Because naming output devices is a privilege browsers hand out sparingly, and two of the four major engines do not hand it out at all. Chromium-based browsers will list outputs through enumerateDevices, but the names stay blank until the site has been granted a microphone at least once — the labels are treated as identifying information. Firefox and Safari do not enumerate outputs to a page under any conditions, so the panel says so rather than inventing a device name.
Does the sample rate shown here matter?
It matters when it is being converted, not when it is merely unusual. The figure is whatever your output device is currently running at, commonly 48,000 Hz on modern hardware and 44,100 Hz on older interfaces, and the browser resamples the clip to match. Trouble starts when two layers disagree and the resampling is done badly: periodic clicks every few seconds, or a slight pitch shift, both point at a sample-rate mismatch in the driver settings rather than at anything on this page.
The clip plays but it crackles. Is that the speaker?
Turn the level slider down first and listen again, because clipping in the browser and distortion in a driver sound similar through a small speaker. The meter shows peaks in decibels relative to full scale, and anything reaching 0 dBFS is being squared off before it ever leaves the tab. If the crackle survives at a quarter of the level, it is downstream, and a cable moved gently at each end while the clip loops will usually find it.
About silence, and why a browser cannot tell you it is silent
A web page has no ears. It can generate samples, hand them to the operating system and watch them go, and there its knowledge stops — nothing in any browser reports back that a cone moved or that a room got louder. That single limit is why this page is built around a meter rather than around a Play button on its own: the meter turns an unanswerable question, did you hear it, into an answerable one, did the machine produce it. Everything after that is a process of elimination down a chain the browser is at the very top of.
The first link in that chain is a rule browsers adopted in 2018 and that still catches people out. Chrome, and then everyone else, stopped letting pages open an audio output without a user gesture, and the way they enforce it is quiet: the context is created in a suspended state, accepts everything you schedule on it, and plays none of it. No exception is thrown and no message appears in the console for a page that never checks. A visitor who lands on a broken audio page therefore sees exactly what a visitor with dead speakers sees, which is why the engine state is printed on this page in words. If you want to keep a tone running while you change something in your system settings, the tone generator holds one indefinitely, and if you want to know how high your ears still reach, that is the hearing test.
Once sound is confirmed to be coming out, the questions that remain are about routing rather than existence, and each has its own page here. Whether the left box is really the left channel, and whether one of them is connected backwards, is the speaker test. The faults that only appear with cups on your head — reversed sides, an image that leans, a driver that buzzes on a low note — belong to the headphone test, and a headset with a boom microphone gets both ends checked at once on the headset test. If a receiver is involved and you need to know which socket ended up carrying the rear channels, the surround sound test addresses them one at a time. And if you are running this because a machine arrived yesterday and the return window is short, the display half of the same once-over is the black screen and white screen fields, which show stuck pixels and backlight problems that a desktop wallpaper hides.
What the meter reads
Every number on this page is worked out by JavaScript running in the tab you are reading it in. Nothing you type, paste or open is uploaded, logged or kept, which is also why the tools carry on working after you disconnect from the network.
The meter is pointed at this page’s own output, not at your room. There is no microphone request anywhere on this page, so nothing here can hear whether the clip arrived — which is also the honest limit of the verdict it gives you.