Microphone troubleshooting guide
Browser microphone test not working? Separate permission, input, and signal problems
Test a browser microphone in a controlled order to distinguish permission, device selection, silence, and clipping without uploading audio.
A microphone test has several jobs. It can show whether the browser is allowed to request an input, whether it receives a signal, and whether that signal is too quiet or clipped. It cannot prove that your voice will sound good in every meeting app. Start by separating those questions instead of changing every permission and audio setting at once.
Run one local microphone reference
Open the WaveLocus microphone test in a secure browser session and choose the microphone you expect to use if the browser offers a choice. Begin with a normal speaking voice. Watch the local meter, then stop the test when you have a clear observation. WaveLocus analyzes the capture in the browser and does not upload the microphone stream.
Browser microphone capture uses getUserMedia(). It requires user permission and a secure context such as HTTPS or localhost. A failed request can reflect a browser permission decision, an operating-system setting, a hardware issue, or page-level access restrictions. A permission prompt by itself does not prove that the correct microphone will supply a usable signal.
Classify the first result
Take note of the browser message, the selected input, and the meter result before changing settings. Those three observations are more useful than a memory of “the mic did not work.” They also prevent a permission fix from being mistaken for a signal-level fix.
Test the permission path once
If the browser blocks access, check the site permission in the browser's current settings. Chrome's official help describes how to allow a site that is listed as unable to use the microphone. Follow the current instructions in Google Chrome Help rather than relying on an old screenshot. After changing one permission, reload the page and run the same local reference again.
Do not grant microphone access to unfamiliar sites just to make a test pass. The correct choice is to grant access only to a site you trust and understand. WaveLocus asks for input only after you start the microphone test, and its privacy page explains what remains local.
Check input selection and system access
- Keep the browser and test the same. Confirm the expected microphone is physically connected, powered, and not muted by a hardware control.
- Select one intended input. If the browser or system offers several microphones, choose one deliberately. Do not switch among several inputs while trying to interpret one meter reading.
- Make one normal reference sound. Speak at a normal distance and level. Avoid tapping, shouting, or monitoring through speakers, which can create misleading peaks or feedback.
- Compare with the operating system. On Windows, use the current input test and privacy controls described in Microsoft's microphone troubleshooting guide. Keep the same microphone connected for this comparison.
- Record the change. If Windows sees a signal but the browser does not, or the reverse, record that difference and continue through guided diagnosis.
Do not confuse capture with sound quality
A moving meter means only that the current browser path receives level. It does not guarantee clear speech, good placement, low room noise, or the exact processing used by a video-call app. Browsers can expose some capture settings, such as echo cancellation, but the actual available settings depend on the browser and hardware. MDN notes that media-capture settings and constraints vary with the user agent and input device. See its constraints and settings guide for the underlying model.
Keep playback and microphone failures separate
A microphone can fail while website playback works, and website playback can fail while microphone capture works. Test each path on its own. If starting microphone capture changes your headset's sound, use the headset test rather than assuming the microphone is broken. That workflow records a before-and-during comparison and carries a failed result into diagnosis without asking you to re-enter the path.
When to stop and use another method
Stop capture if you are in a sensitive environment or do not want a browser to access the microphone. Do not route a live microphone back through open speakers unless you understand the feedback risk. If the operating system does not detect the device at all, check the physical connection and use the manufacturer's support method before repeatedly changing browser permissions. A browser meter is not a hardware certification or a recording-quality guarantee.
Next step
Preserve the narrowest true statement. For example, “Windows input test sees the USB microphone, but Browser A's local test has no signal” is actionable. “My microphone is broken” is not. Record the source, connection, selected input, permission outcome, and meter result in guided diagnosis so the next comparison changes only one variable.
Sources and method
This guide uses a browser-local WaveLocus capture reference. It relies on MDN's getUserMedia documentation, Google Chrome Help, and Microsoft's current microphone guidance. It does not claim to certify a microphone or diagnose a meeting application.