Media Capabilities Check - Devices and Codecs
docInspect camera and microphone access, device enumeration, and codec support to diagnose media failures and reduce fingerprint exposure from media device APIs.
Media Capabilities Check
Inspect camera and microphone access, device enumeration, and codec support.
What this tool checks
The report verifies camera and microphone permission state, enumerates available input/output devices, and checks practical codec availability for browser recording and playback paths.
It focuses on operational diagnostics: whether your current browser session can actually access media hardware and negotiate formats used by real meeting or streaming workflows.
Why this matters in real workflows
Video calls fail most often because of permission drift, device contention, or codec mismatch—not because the internet is down. A quick capability check before a critical meeting prevents avoidable outages.
Support and IT teams can use this page as a standardized preflight baseline, reducing back-and-forth when users report "camera not working" or "no audio" issues.
How to interpret common outcomes
No devices listed: check browser site permissions, OS privacy toggles, and HTTPS context first. Browsers may block media APIs on insecure origins.
Only default device shown: external devices may not be recognized by the OS, or the browser may hide labels until explicit permission is granted.
Codec unsupported: start with broad-compatibility profiles like H.264 + Opus, then test VP9/AV1 where efficiency matters and target clients support them.
Five-minute troubleshooting sequence
Close applications that can lock devices (meeting apps, screen recorders, virtual camera tools), refresh, and retest.
If the issue persists, run the same check in a clean browser profile or a second browser. This quickly separates browser-policy or extension interference from OS/device problems.
Privacy and governance considerations
Device enumeration behavior, label exposure, and API availability can contribute to browser fingerprinting. Use least-privilege permissions and avoid permanent grants for untrusted sites.
In managed environments, allow media permissions only for approved domains and document policy baselines so updates do not silently break collaboration tools.
Frequent root causes
Typical causes include enterprise policy restrictions, stale or conflicting audio drivers, virtual-device collisions, and browser updates that reset permission defaults.
Remote desktop and cloud browser sessions may expose virtual media channels, so results can differ from local desktop testing even with the same account.
Scope and limitations
This page captures capability at test time for the current browser + OS session. It does not guarantee end-to-end call quality under real network congestion or provider-side throttling.
For production incidents, pair this result with network path checks and protocol diagnostics to avoid blaming media APIs for transport-layer problems.
Related Tools
Related Docs
- WebRTC Leak Test — WebRTC media path and ICE candidate analysis
- Browser Fingerprint — how media device signals contribute to fingerprinting
Frequently Asked Questions
How do I check camera and microphone access?
Use IPOK's Media Capabilities Check tool to inspect camera and microphone permission states, enumerate available input/output devices, and check codec availability for your browser session. Check browser site permissions first — browsers may block media APIs on insecure origins (non-HTTPS) or in private mode.
What codecs does my browser support?
Codec support varies by browser and device. Most browsers support H.264 and Opus for video and audio respectively. VP9 and AV1 support depends on hardware decoder availability. Use the Media Capabilities Check tool to see which codecs are actually exposed in your current environment, since support can differ between desktop, mobile, and cloud browser sessions.
Why does my browser not detect media devices?
If no devices are listed, check browser site permissions (Settings → Site Permissions → Camera/Microphone), OS privacy toggles, and HTTPS context first. Browsers may hide device labels until explicit permission is granted. External devices may not be recognized by the OS, or a conflicting application may be locking the device.
Can media device enumeration cause fingerprinting issues?
Yes. Media device enumeration — the list of available cameras, microphones, and speakers exposed to JavaScript — can contribute to browser fingerprint uniqueness. The number and names of devices can identify your hardware setup. Use least-privilege permissions (ask-by-default) for untrusted sites and avoid permanent media grants to reduce this exposure.