HEVC Compatibility: Chrome, Edge, Windows, Audio & Containers

The current HEVC compatibility guide for Chrome, Edge, Windows, audio codecs, containers, and browser playback limits.

Last updated: 2026-08-04

Why this page exists

Compatibility pages are useful only when they are explicit about what is supported today and what is still outside the guaranteed path. This page describes the current browser playback scope for OpenHEVCVideo in plain user terms.

Browser target: Chrome, Edge, and Windows

The primary target is Windows on Chrome and Edge. Other platforms and browsers may work for some files, but Windows users on Chrome or Edge are the clearest fit for native HEVC detection, Microsoft HEVC extension guidance, and local browser playback.

Preferred file shapes

The practical target is:

MP4 or MOV containers,
HEVC Main or Main10 SDR video,
local file playback through the OpenHEVCVideo player.

These combinations are the clearest fit for native probe plus compatibility fallback behavior.

Audio expectations

Audio must be treated separately from video.

AAC may work, but the result should still be confirmed by actual file probe.
Opus may work in some cases, but it should also be treated as probe-dependent.
AC-3 and E-AC-3 are not guaranteed in the current browser player.

If a video plays without sound, that does not automatically mean the HEVC video track failed. The issue may be limited to the audio stream.

Formats and workflows that are not guaranteed

The current support scope does not promise:

4K playback on all devices,
HDR correctness,
DRM playback,
every MKV workflow,
every raw .hevc or .h265 stream,
every frame rate or chroma layout,
every hardware-acceleration path.

These cases may work for some users, but they must remain outside the guaranteed support statement until verified by dedicated fixtures and browser testing.

Native playback versus compatibility mode

Two users can open the same nominal format and still land on different paths:

one may get browser-native playback,
another may fall back to compatibility mode,
a third may fail because of memory limits, audio, or metadata.

That is why the product should surface the observed playback path rather than relying on a static support table alone.

How to interpret support claims

OpenHEVCVideo support claims should be read in this order:

Can the actual file be opened natively in the current browser?
If not, can the local compatibility path decode and present it?
If not, is the blocker the container, audio codec, profile, resolution, HDR, DRM, or memory budget?

To test the current behavior directly, open the HEVC player.