Why Are Website Media Devices Different?

A website may show a camera, microphone, or speaker list that differs from the devices visible in the operating system. This does not by itself prove that the wrong profile launched. The page can see only the media devices the browser makes available to that page, and the result also depends on site permission, page security, and the profile’s Media device profile setting.

Understand what the website can read

Websites commonly call navigator.mediaDevices.enumerateDevices() to request available audio input, audio output, and video input devices. The result has important boundaries:

• the page must run in a secure and active browsing context;
• browser permission policy can remove cameras, microphones, or speaker-selection entries;
• non-default devices may remain hidden until the site receives the relevant permission; and
• device labels are normally blank until an active media stream exists or persistent permission has been granted.

The list can therefore look different before and after a permission prompt without any profile setting changing. A blank label is also different from a missing device: record the device kind and count before concluding that the camera or microphone disappeared.

Read the media device profile correctly

MaskPilot treats the microphone, camera, and speaker topology as one profile setting. Use real devices is the default so a new profile does not unexpectedly replace the device’s actual camera or microphone.

The available choices describe the intended topology:

• Use real devices keeps the actual media-device topology.
• Muted virtual speaker only selects only a virtual output device.
• Virtual microphone and speaker selects virtual audio input and output devices.
• Virtual camera and speaker selects a virtual video input and audio output device.
• Full virtual media devices selects the complete virtual microphone, camera, and speaker topology.

This setting does not install physical hardware, grant a website permission, or guarantee that every meeting or recording service accepts the selected devices. Choose it for the workflow you intend to test, not to force one diagnostic page to display a preferred result.

Verify the same profile before editing

1. Open the affected HTTPS page in the target profile and note whether the site already has camera or microphone permission.
2. Record only the listed device kinds, counts, and whether labels are blank. Avoid sharing hardware serials, account details, or permission screenshots containing sensitive site data.
3. Fully close the profile and wait until it becomes available again.
4. Edit that profile and locate Media device profile in the fingerprint settings.
5. Confirm the saved choice without changing the browser version, WebRTC policy, proxy, and several fingerprint settings at the same time.
6. If a change is necessary, save one choice, fully relaunch the same profile, and repeat the test on the same page.

Media-device settings are read when the browser process starts. Saving the form does not rewrite a process that is already running. If the old result remains after a full relaunch, follow why profile settings did not apply before making another change.

Separate permissions from device topology

When a website cannot use a camera or microphone, first determine which stage failed:

• No device label before permission: this can be normal privacy behavior. Grant permission only when the site and workflow require it.
• Permission denied: review the site’s browser permission and the operating system’s camera or microphone access. Changing the media-device profile does not override either permission layer.
• Device listed but capture fails: the device may be busy, unavailable, or unable to satisfy the site’s requested constraints. Test the actual call or recording flow instead of relying only on the enumeration list.
• Real-time connection fails after capture starts: device enumeration and WebRTC network routing are separate. Use the WebRTC proxy-route checklist for an IP or connection-path problem.

The browser’s media list is one observable surface, not a diagnosis of why a site challenged a session. Keep the profile stable and change one variable at a time.

Choose the smallest safe correction

Keep Use real devices when the workflow needs the device’s actual microphone or camera. Select a virtual topology only when the workflow explicitly requires it, then test device selection, permission, recording, and playback in a test profile before using the same choice elsewhere.

Do not rotate the setting between launches or combine it with unrelated screen, language, hardware, WebGL, and browser-version changes. For the broader configuration lifecycle, see configure a stable browser fingerprint.

MDN documents the permission and visibility boundaries of enumerateDevices(). The W3C Media Capture and Streams specification also identifies device information as a fingerprinting surface and defines when camera and microphone details may be exposed.