← Back to Performance Tests

No Camera Needed

Browser Codec Inspector

Every browser decides independently which video codecs it can encode, decode, and run on dedicated hardware — and none of that shows up anywhere in a normal settings menu. This reads it straight from the browser's own WebRTC and Media Capabilities APIs: exact codec support, plus whether each one is hardware-accelerated on your current device. No permission prompt, because none of this requires your camera or microphone.

Your Browser

Detecting…

Checking codec capabilities…

Video

Video Codec Support

CodecEncodeDecodeHW EncodeHW Decode

Audio

Audio Codec Support

CodecClock RateChannels

Share

Share Your Result

Notes

Why hardware acceleration matters more than the codec name

A codec is just a specification — the actual work of squeezing video down to a bitrate happens in an encoder, and that encoder can run in two very different places. A hardware encoder is a small dedicated chip built for exactly this task; it is fast and barely touches your battery. A software encoder does the same math on your general-purpose CPU, which works but costs far more power and can push fan noise up noticeably on a long call.

Two devices can both "support" the same codec while one runs it on silicon built for the job and the other burns CPU cycles instead. That difference is exactly what the HW Encode and HW Decode columns above report.

Reading the table

Encode / Decode = NoYour browser cannot use that codec on a WebRTC connection at all, in either direction.
HW column = NoSupported, but running in software. Fine occasionally; on a long call it is the difference a warm laptop and a loud fan usually trace back to.
HW column = "not reported"Your browser does not expose a hardware-acceleration signal for that codec. It may still be accelerated — this is a gap in what the browser tells the page, not a negative result.

What this does not tell you

Conferencing apps like Zoom, Teams, and Meet mostly use their own native encoders rather than the browser's, so a desktop-app call can behave differently from a browser-tab call on the same machine. This tool reports what the browser itself can do — the most relevant figure for Google Meet, Discord, or any other tool you use inside a tab.

Benchmark Reference

Common Codec Families

CodecCompatibilityHardware support
H.264 / AVCNear-universalBroad hardware support across most modern devices.
VP8Wide (WebRTC default fallback)Usually software on many devices.
VP9Common in recent browsersMixed — check your own result.
AV1Growing, decode more common than encodeHardware encode limited to newer GPUs/chipsets.

General characteristics, not a guarantee — your device's actual support is exactly what the table above measures.

Step-by-Step

How to Run the Test

  1. Load the page — no camera or microphone permission is needed for this test.
  2. Read the codec table for encode/decode support and hardware-acceleration signal per codec.
  3. Check your verdict — the browser's best available hardware-accelerated option.
  4. Compare across browsers by running the same test in each one you use, since results genuinely differ.

Common Questions

Frequently Asked Questions

Which video codec is best for calls and streaming?
Whichever one your browser reports as hardware-accelerated. Codec choice matters less than whether the encode runs on a dedicated chip or on your CPU — a hardware-accelerated VP8 stream will use less battery and generate less fan noise than a software AV1 stream, even though AV1 is the newer, more efficient format on paper.
What does hardware-accelerated actually mean here?
It means your device has a dedicated chip for that specific codec, so your CPU does not have to do the encoding or decoding work in software. This tool reads the browser's own powerEfficient signal from the Media Capabilities API rather than guessing from codec name alone.
Is AV1 supported for video calls yet?
Decode support is now common in recent Chrome, Edge, and Firefox. Hardware-accelerated AV1 encode is still limited to newer GPUs and some recent phone chipsets, so most devices that can decode AV1 are still encoding it in software, if at all — check your own result above rather than assuming.
Why does my result differ between browsers on the same computer?
Each browser ships its own codec implementations and decides independently which ones to expose through hardware acceleration, even on identical hardware. Chrome and Edge share an engine and usually match; Firefox and Safari often differ from both and from each other.
Does this require camera or microphone access?
No. This reads codec capability information directly from the browser's Media Capabilities and RTCRtpSender APIs — no camera or microphone permission is needed at all.