How to test mic and camera before a Google Meet call
There are two reliable paths, and they answer slightly different questions. Path one uses Google's own pre-join interface (called the green room) and is the closest match to what Meet will do once you hit Join. Path two uses our browser tester and works even when you do not have a meeting link to open — useful before your first call of the day, or when you are about to be the host and do not want a half-broken setup at go-time.
Path 1: Use Meet's green room (meet.google.com/<id>)
Open or create a Meet link in Chrome, Edge, Safari, or Firefox. You land on a preview screen with your video tile in the centre and a row of device controls below. Per Google's own help docs: click Microphone and speak — if the mic bar moves, your mic works. Click Speaker, then Test speakers — if you hear a tone, your speaker works. Click Camera — if the preview shows your face, your camera works. Use the dropdown arrows to pick a different input device on any of the three.
Caveat: Meet does not expose a standalone test page. You have to create or open a meeting to reach the green room, which means committing to a calendar event slot or generating a throwaway link.
Path 2: Use Clipy's tester without joining a meeting
- 1
Open the tester. Use the same browser profile you will use for Meet. Permissions are stored per-origin, so a fresh profile means you grant access twice.
- 2
Click Allow. Camera and microphone access is the same prompt Google Meet shows on first use. Granting it here does not leak access to meet.google.com — origins are isolated.
- 3
Confirm the camera preview. The live tile is rendered straight from the browser's MediaStream — identical to the frame Google Meet would composite into your participant tile.
- 4
Speak and watch the level bar. We sample the mic 60 times a second via the Web Audio AnalyserNode and convert peak amplitude to a 0–100 bar. Movement means audio is reaching the browser.
- 5
Switch devices and lock in the right hardware. The dropdowns enumerate the same input devices Meet sees. Pick the right one once, and Meet will default to it on the next call.
When both bars and tiles confirm working hardware, open meet.google.com, paste your link, and join. The green room will already have the right devices selected. Open the live tester →
Why Google Meet can't hear you
These are the five causes that account for the vast majority of "you're muted, we can't hear you" complaints in Meet. None of them are bugs in Google Meet — all five are fixable in under a minute once you know what to look at.
- Chrome site permission for meet.google.com
Chrome stores camera and mic permission per-origin. If you ever clicked Block on a Meet permission prompt, Meet stays muted even when other sites work. Click the lock icon in the address bar, set Microphone to Allow, then reload meet.google.com.
- Wrong OS-level default input
macOS and Windows pick a default input device that can quietly change when a Bluetooth headset connects or a USB mic unplugs. Open the device dropdown in Meet's green room — or in our browser tester — and confirm the correct mic is selected before joining.
- Bluetooth headset latency or mode switch
Most Bluetooth headsets run in two modes: high-quality A2DP for music and lower-quality HFP/HSP with a working mic. When Meet activates the mic, the headset drops to HFP, which sounds tinny and adds 100–300 ms of latency. For important calls, a wired headset or built-in mic usually wins.
- Another app is holding the mic exclusively
On Windows in particular, an open Zoom, Teams, OBS, or Loom session can hold the microphone in exclusive mode. Meet then gets a working device handle but zero audio. Quit those apps fully, then reload the Meet tab.
- Meet itself is muted at the toolbar
Easy to miss after re-joining or being placed in a waiting room: the mic icon at the bottom of the Meet window is toggled off. The red strikethrough is small. Hover and click to unmute.
If none of the five apply, run the standalone mic test first. If the level bar moves there but Meet still hears nothing, the issue is the per-origin Chrome permission for meet.google.com.
Google Meet camera issues
A black tile, a frozen first frame, or a camera-disabled icon in your participant view usually comes from one of these five. Google's official camera troubleshooting guide covers the first two; experience covers the rest.
- Another app is using the camera
Only one app can read the camera at a time on macOS and Windows. If Photo Booth, OBS Virtual Camera, Zoom, or Teams is open in the background, Meet shows a black tile or the camera-disabled icon. Quit those, reload Meet.
- Browser or OS permission blocked
Three layers can block the camera: the website (lock icon in the address bar), the browser (chrome://settings/content/camera in Chrome), and the OS (System Settings → Privacy & Security → Camera on macOS; Settings → Privacy → Camera on Windows). All three must allow your browser.
- Low light triggering brightness boost
Google Meet auto-brightens dim video. In very low light the preview can look washed out and faces lose detail. Add a desk lamp pointed at your face or open a curtain — the boost relaxes when there is real light to work with.
- Virtual background or filter stuck loading
Background blur, replacement images, and visual filters load extra ML models. On older hardware they can stall and leave the camera tile frozen on the first frame. Turn off effects via the three-dot menu, then reload.
- Mirrored preview makes you think the wrong cam is on
Meet mirrors your self-view by default — text behind you reads backwards. Other participants see the un-mirrored version. If you are debugging which camera is active, point at something asymmetric in the room rather than reading on-screen text.
For a camera-only sanity check that bypasses Meet entirely, run the standalone webcam test. If the preview is fine there but black in Meet, an exclusive hold from another app is the most likely culprit.
Same test, also valid for Zoom, Teams, and Slack
Google Meet, Zoom on the web, Microsoft Teams in the browser, and Slack Huddles all read from the operating-system camera and microphone through the same WebRTC stack the browser exposes. A working camera and microphone in Clipy's tester predicts a working device in all four — the only way that statement can fail is if a second app grabs an exclusive hold on the device between the test and the call.
Practical workflow: run the tester once before your first call of the day, leave the Clipy tab closed, then join meetings without re-testing. Re-run only when a new device is plugged in or after an OS update.
What we do — and do not — do with the stream
The camera feed renders straight from the browser's MediaStream into the preview tile. There is no MediaRecorder running, no canvas capture, no upload. The mic stream feeds a Web Audio AnalyserNode that reads peak amplitude locally to draw the level bar — also no recording. Open the network tab while the test is running and you will see zero requests on the media stream.
When you close the tab, the browser releases the devices and your webcam indicator light turns off. No background process holds the camera or microphone open.