Microphone works in browser but not in a meeting app
Use a successful browser microphone test to narrow down meeting-app input selection, mute controls and permissions before replacing equipment.
If Microphone Tester records your voice clearly but a meeting app stays silent then the microphone can capture sound in at least one working configuration. Keep that result as evidence. It narrows the problem but it doesn’t prove every setting in the meeting app is correct.
Confirm which device passed
Listen to the recording and make sure it came from the intended microphone. A laptop’s built-in input can pick up your voice while a disconnected headset sits nearby. If several inputs are available then compare their names with the input selected in the meeting app.
Speak at the same distance you’ll use during the call. A microphone that only seems audible when you lean close to the laptop may not be the headset input you meant to test.
Inspect the app’s input selection
Open the meeting application’s audio settings or pre-join screen. Choose the intended microphone explicitly when the app offers that choice. “Default” can follow an operating-system selection that changed after you connected a dock or headset.
For a useful comparison keep the physical connections unchanged. If the app names the input differently then unplugging and reconnecting the device can help identify which entry changes. Stop any recording before disconnecting equipment.
Check each mute control
Look for an inline headset switch and the application’s own microphone button. Some devices have a physical mute indicator while the meeting app shows its software state separately. Neither display necessarily tells you the state of every other control.
If the application includes an input meter then speak while watching it. Movement is a useful clue but verify actual playback through the app’s test feature where one exists. Don’t treat a bouncing bar as proof that the remote participant receives intelligible speech.
Review access for the failing application
Operating-system access and website permission are separate checks. Microsoft notes that enabling a camera or microphone for Edge still leaves individual websites responsible for requesting permission. Microsoft’s privacy guidance explains those layers.
Use the settings for the actual meeting site or desktop app. A permission granted to Hardware Detective doesn’t carry across to another domain. If the setting is managed by your organization then ask its support team rather than repeatedly changing unrelated browser options.
Compare processing after capture works
Once the app receives your voice compare its noise suppression and automatic-level options if they’re available. A setting that suppresses background noise can also change quiet speech or music. Make one adjustment and repeat the same phrase.
If both browser recording and the app’s own recording work but a participant still hears nothing then check meeting mute state and connection symptoms. Ask whether the participant hears anyone else. The remaining failure may be outside your microphone path.
Record the working device name and the setting you changed. That gives you a short recovery checklist if reconnecting a headset causes the same problem next time.
Common questions
Can browser permission enable the microphone for every app?
No. Permission for this website isn’t permission for another website or a separate desktop application. Check access for the application that is actually failing.
Should I reinstall the microphone driver first?
A readable local recording is a reason to inspect the app’s selection and permissions first. Reinstalling software immediately adds another variable without explaining why one application already receives sound.
Does a moving microphone meter prove people can hear me?
No. It shows that some signal reaches that meter. The app can still be muted or the connection can fail later in the path. Use a test recording or a meeting with a willing participant to check the final result.