Camera & Microphone Test

This is the part of the page worth reading carefully. With no permission at all, a site can call navigator.mediaDevices.enumerateDevices() and receive one entry for every camera, microphone and audio output your browser knows about. What it does not receive is the name of any of them.

Each entry carries a kind, which is one of three strings, an empty label, and a deviceId that is either blank or a value salted per origin so it cannot be matched across sites. From that, a page learns the shape of your hardware: that you have one webcam and two microphones, say, without knowing a single brand name. That is what the panel shows before you press the button.

When you grant camera or microphone access, the same enumerateDevices() call starts returning real labels, for example the model name of your webcam and the friendly name of each microphone. The device identifiers become stable for that origin too, so a site can recognise the same camera on your next visit without a cookie.

The button above deliberately asks for both camera and microphone at once, because that is the broadest grant a page can request. If you allow it, the panel re-reads the list and the names appear. If you refuse, nothing changes and the message under the button says so. Note that the prompt is all or nothing in most browsers: you cannot allow the microphone and block the camera from the same call, so a site that only needs the microphone can still ask for both.

The kind field is a short string, and the three values are worth knowing because each one behaves differently.

• audioinput covers microphones, headsets and any virtual capture device, including loopback drivers that record what the system is playing rather than what a room sounds like.
• videoinput covers webcams, capture cards and virtual cameras such as a screen-capture or streaming tool creates.
• audiooutput lists speakers and headsets the page could send audio to. It has no capture capability, so it is the harmless one, though the number of outputs still adds a small signal.

The panel labels each row with its kind and a running number, so a machine with several microphones is easy to read at a glance.

Before permission, the number of devices is one of the few things a page can learn about your hardware for free. Most laptops report one camera and one or two microphones, so the common case blends into the crowd. A machine with four cameras, a capture card and a virtual loopback device is far rarer, and those counts help narrow down who you are.

Browsers have already pushed back on this. Once you deny permission, most now return a default entry of each kind with blank labels rather than an exact inventory, precisely so the count itself stops being a reliable fingerprint. That mitigation is why the panel above may show one microphone on a machine that has none. Treat the counts as approximate, not exact. The fingerprint test shows how this signal stacks with the rest.

The Media Capture spec fixes the shape of the API but leaves the details to each browser, so what the panel shows depends on what you run. Chromium browsers were once the most revealing before a grant, listing every device with a blank label; they have since narrowed to a single placeholder entry of each kind, which is what you see above on Chrome and Edge. Firefox adopted that approach earlier and is stricter about identifiers, handing back an empty deviceId in more cases. Safari is stricter again, requiring a user gesture before getUserMedia will run at all, so a page that asks the moment it loads is refused.

Access is remembered per site, so granting it once above does not grant it to other sites, but it does persist here until you change it. To revoke it, open the site permissions panel in your browser, usually from the padlock or controls icon next to the address bar, and set camera and microphone back to ask or block. The names will go back to being hidden on the next reload.

The other habit worth keeping is watching the indicator light. A camera light that stays on after you close a tab means a stream was left running, which is a fault in that site rather than a feature of the browser. This page cannot leave one on, because it stops every track the moment it has what it came for. For the full set of permissions a page can query, try the permissions test, and for the rest of your device surface see the device and hardware test.

You cannot make enumerateDevices() return nothing, and blocking the camera does not remove the call. What you control is whether the labels and the stable identifiers are available to a site. Start by checking what this browser already grants: the permissions test reads the camera and microphone permission state directly, so you can see whether a standing grant exists rather than guessing.

To keep your hardware unnamed, leave the permission on ask rather than always allow, and refuse the prompts that have no reason to be answered. A browser with fingerprinting defences will also generalise the list, so the counts shrink toward placeholders. If what you want is certainty that nothing is captured, rely on something above the browser: a physical cover, a hardware switch, or the indicator light. This page reads names, never frames.