DeviceBenchFree pre-meeting check
Check your call setup five minutes before the meeting
One button opens the camera and microphone together from a single prompt, the way a meeting client asks, then times 20 round trips to a file on this domain and lets you record five seconds and play them straight back — about a minute end to end. Five rows settle green or red — camera, microphone, whether your voice is arriving at all, speakers, and how steady the line is. Four of them the page can settle for you; no browser can hear its own output, so the speaker row is the one you mark yourself.
- 100% free
- No signup
- 5 checks
- 5-second playback
- 20 latency probes
One prompt covers both devices, the same way a meeting client asks for them. Nothing opens until you press the button.
The input meter starts when a microphone track opens
- CameraNot asked for yet
- MicrophoneNo live audio track
- Your voiceWaiting for a microphone
- SpeakersRecord five seconds first; a browser cannot hear its own output
- ConnectionNot started
- Five rows, four of which the page can settle for you.
The connection row times 20 web requests to a file on this domain, which is the shape of a page load rather than of a call: a meeting runs over UDP to servers of its own, so a green row says your line is steady right now, not that a particular meeting will hold together.
How to check a call setup before you join
Devices first, your own voice second, the line last — that is the order the fixes get harder in.
Allow both devices at once
Run the check asks for the camera and the microphone in a single request, which produces one prompt and is exactly the shape of request a meeting client makes. It is also all-or-nothing: if either device is missing, switched off or blocked, the whole request fails and both rows go red together. That is worth knowing before you conclude your camera is at fault when the microphone was the problem.
Say a sentence, then record five seconds
The input meter needs sound to move, so read something aloud at the volume you would actually use. The voice row turns green as soon as a peak above -40 dBFS arrives and stays gray if nothing does — which is what a muted headset cable, a hardware mute key or the wrong input device looks like. Then record: hearing your own microphone played back is the only honest check on what it really produces.
Work down the red rows in order
Camera and microphone first, because everything else depends on them, and in each case check the device, then the browser permission, then the operating system's own privacy switch. Settle the speaker row by playing the clip and saying whether you heard it. Leave the line for last: it is the only row you cannot fix in the next four minutes, and knowing it is shaky is still worth having before you join.
Technical specifications
| Checks run | Five — camera track live, microphone track live, an input peak above -40 dBFS, speaker output confirmed by you, and a latency run |
|---|---|
| Probes | 20 requests spaced 250 ms apart to a file on this domain, with the cache defeated on every one |
| Green line | Median under 100 ms with wobble under 30 ms; above that a jitter buffer starts paying for the spread in delay or in dropped audio |
| Clip length | 5 seconds, held as a blob in memory, replaced on the next take and released on reload |
| Recording format | WebM with VP9 or VP8 video and Opus audio where the browser offers it, MP4 on Safari |
| Microphone facts read | Sample rate and channel count from the live track — 48,000 Hz on a wired or USB microphone, 16,000 Hz or lower once a Bluetooth headset takes the input |
| Output device | Selectable for the playback clip in Chromium browsers; Firefox and Safari play through the system default and ignore the page |
| Price | Free, no signup, no account and no meeting link required |
Frequently asked questions
My camera works here but the meeting app shows a black square.
The app is almost certainly holding on to a device you are no longer using. Zoom, Teams and Meet each enumerate the hardware themselves and remember a specific device rather than following the system default, so the webcam you unplugged last week is still the one selected in their settings. Two other things differ from a browser: on Windows only one process can hold a camera at a time, and browser permissions are stored per address, so meet.google.com and teams.microsoft.com are separate grants that have to be given separately.
Why does my Bluetooth headset sound like a phone call the moment I unmute?
Because opening the microphone forces the headset off its music profile. A2DP carries audio one way in stereo at up to 328 kbit/s; the instant anything needs the microphone, the link switches to the hands-free profile, where both directions share one channel at 8 kHz with CVSD or 16 kHz with mSBC. Nothing is broken and no setting will avoid it — the fix is to take input from the laptop or a USB microphone and leave the headset doing output only.
People say they hear an echo of themselves.
Your speakers are reaching your microphone, and the far end hears their own voice come back a moment late. Browsers turn echo cancellation on by default for a captured microphone, but it can only subtract sound the browser itself played — audio from another application, or a loud room with a hard wall, walks straight past it. Headphones end the problem completely in one move, which is why every support script starts there.
Which speaker will the meeting actually use?
Whichever one the meeting app has remembered, not the one the browser is using. A Chromium browser will let a page choose an output device, and the playback clip on this page offers exactly that, but a desktop meeting client keeps its own list and ignores both the browser and, quite often, the system default you changed five minutes ago. Set it inside the app itself while you are still in the waiting room.
Is 40 ms good enough for a call?
Comfortably: the long-standing telephony guidance is that one-way mouth-to-ear delay under 150 ms goes unnoticed, and 40 ms of network latency leaves plenty of room for the encoding and buffering piled on top of it. What ruins a call at 40 ms is inconsistency rather than the number itself, because a jitter buffer has to grow until it covers the worst arrivals and then charges you that growth as delay. The ping test and the jitter test on this site each measure one of those over a longer run.
Do I have to install anything or sign in to test before a meeting?
No — there is no download, no account and no meeting link needed. Everything here runs in the tab you already have open, which is the point: five minutes before a call is not the moment to install a client, restart a machine or find a password.
Can I test the actual meeting link before I join it?
No page can do that, including this one. A meeting service carries media over its own transport to its own servers, and nothing in a browser tab can reach into that path from outside. What this settles is your side of it — that the devices open, that your voice arrives, that sound comes out, and that your connection is steady enough right now — which is where the overwhelming majority of five-minutes-before problems actually are.
About what a meeting app takes from your machine
A browser and a desktop meeting client can look at the same laptop and disagree completely about it, and the reason is that they choose devices in different ways. The client enumerates the hardware itself and stores the one you picked, by identifier or by name, and it keeps that choice through reboots and through the headset you plugged in afterwards; the browser follows the operating system default unless a page asks for something specific. Add the Windows rule that a camera belongs to one process at a time — macOS is happy to share it — and you have the everyday situation where the picture is perfect on this page and black in the app running beside it. When that happens, the device is not the thing to replace: the setting inside the app is. The webcam test confirms which camera your browser actually opened, which is the fastest way to prove the hardware is fine.
The audio trap catches more people than the video one, and it is entirely a Bluetooth story. A wireless headset streaming music is on A2DP: one direction, stereo, SBC at up to 328 kbit/s. Ask it for a microphone and the whole link drops to the hands-free profile, where both directions share one narrow channel — CVSD sampled at 8 kHz, or mSBC at 16 kHz on newer hardware — which is why the music you were listening to turns to mud the second you join. Windows admits this openly by exposing one headset as two devices, Headphones and Headset, and picking the first for output while giving input to a laptop or USB microphone keeps you in stereo. This page prints the sample rate it reads off your live track for exactly that reason: 48,000 Hz means you are on a proper input, and 16,000 Hz or less means the headset has already switched. The headset test takes the earcups and the boom microphone apart one at a time if that is where the trouble is.
The last row deserves its own caution. Twenty timed web requests to a nearby edge node describe your connection at this moment; they say nothing about the path to a meeting service, which carries media over its own transport to servers somewhere else entirely. Read a green line as a reason to stop worrying about your Wi-Fi, not as a promise about the call. If it comes back red, the ping test runs the same probe long enough to see a pattern, and if the microphone row was the problem the mic test gives it a full meter and a longer recording. One last thing worth doing while you wait in the lobby: a second monitor throwing light and notifications at you is a distraction for everyone, and the black screen blanks it for the length of the call.
What happens to the five seconds you record
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 clip never becomes a file: it stays a blob in this tab’s memory, the player is pointed at it directly, and recording again discards the previous one. A reload or a closed tab releases it too. There is no button to keep it, because a five-second test take is not something anyone needs to file.