How to test your microphone online without uploading your audio
Use a microphone test that waits for your permission, processes audio locally, shows the selected input and stops the stream when you finish. Speak normally for a few seconds and look for a stable response rather than tapping the microphone. A moving meter confirms that the browser received samples. It does not prove that every meeting app uses the same microphone or processing.
Prepare one clear microphone check
Connect the microphone or headset you intend to use before opening the test. Close any app that may be actively using the device if it prevents the browser from opening the input. Keep speakers quiet during the check. If you later use local playback, wear headphones so the microphone does not pick up its own output and create feedback.
Open the WaveLocus microphone test and select Allow microphone. Browsers use getUserMedia() to request an input stream. MDN documents that this request requires a secure context such as HTTPS and explicit user permission. A denied request, missing input, or unreadable device is different from a microphone that opens but delivers silence.
Check the selected input before judging the sound
A laptop may expose its built-in microphone, a webcam microphone, a USB interface, and a wireless headset at the same time. Confirm the displayed input label when the browser provides one. If the expected device is missing, reconnect it and repeat the request rather than adjusting gain on the wrong input.
WaveLocus also displays browser-reported track settings when they are available. The MediaStreamTrack getSettings() reference explains that these are the settings currently applied to the track. They can include items such as sample rate, channel count, echo cancellation, noise suppression, and automatic gain control. A reported setting describes the browser capture track. It is not a full specification for the microphone or the final settings inside another application.
Run the test in a controlled order
- Allow access deliberately. Read the browser prompt and approve only the microphone you want to test. Do not grant access to an unrelated page or embedded frame.
- Speak at your normal distance and volume. Use a full sentence. Tapping the microphone can produce a spike even when speech is too quiet or the wrong device is selected.
- Watch the level and waveform together. Look for a response that follows speech, returns toward the background level, and does not remain pinned at the top.
- Make one short local recording. Record a few seconds, stop, and play it back locally. Listen for intelligibility, severe noise, interruptions, or obvious clipping.
- Stop the microphone. End the test and confirm that the browser or operating-system microphone indicator turns off.
WaveLocus keeps the analysis and short recording in the current browser session. The test does not send microphone audio to the server. Browser permission is still meaningful, so use the Stop control when the observation is complete.
Interpret the result without overclaiming
Do not treat a browser meter as a calibrated loudness reading
Browser microphone levels are normally expressed relative to digital full scale. They are useful for comparing the same path under controlled conditions. They are not physical sound-pressure levels at the microphone. The conversion depends on the microphone, preamp, gain, processing, operating system, and calibration. Read the dBFS versus dB SPL guide before using a browser number as a loudness claim.
Echo cancellation, noise suppression, and automatic gain control may change speech, background noise, channel count, and level over time. Record the reported settings when available. Do not assume that switching off processing is always better. A meeting app may intentionally use different processing from a browser test.
If the microphone works here but fails elsewhere
A passing browser test narrows the problem. It shows that this browser origin obtained a working input under the current conditions. It does not show which device another application selected. Keep the microphone connected and check the input selector, mute state, permission, and level inside the failing application. Avoid reinstalling drivers or changing several system settings before making that comparison.
If the microphone fails in WaveLocus, use the microphone troubleshooting guide. It separates permission, device selection, silence, and clipping in a controlled order. If opening the microphone changes headset playback quality, move to the combined headset workflow rather than treating it as an unrelated speaker fault.
Protect privacy during the test
Browser microphone APIs require permission and visible use indicators. MDN notes that browsers must show when a camera or microphone is in use and when permission has been granted. Test with an ordinary sentence that contains no confidential information. Stop the stream when finished, and review the site permission from the browser address bar if you do not want it retained.
Next step
Save the input label, browser-reported settings, meter observation, and local playback result. If the test fails, open guided diagnosis and change one element of the input path. If the test passes but a call application fails, keep this result as the known-good comparison and investigate the application layer.
Sources and method
This guide uses the local WaveLocus microphone meter, waveform, settings display, and short in-memory recording. MDN documents the permission, secure-context, error, privacy-indicator, and applied-track-setting behaviour of the underlying browser APIs. The method confirms browser-visible capture and a user-reviewed recording. It does not upload audio, calibrate SPL, certify microphone quality, or prove another application's input path.