Skip to content

AV1, H265 support in 2026: Data from 1M+ devices

Data from the Codec Support Dataset — 363,330,358 individual codec tests across 1,142,586 real user sessions. See methodology for collection details.



While there is a lot of talk in the video/streaming industry about codecs like AV1 and HEVC, as far as I’m aware there is no hard data on how widespread support for these codecs is across devices, which is one of the most important things you would want to know when making codec choices for a video application.

The closest analogues available are:

  • ScientaMobile, which measures codec adoption from chip specfications and market reports of chip distribution
  • Bitmovin Developer report - which is a survey of developers on what codecs they implement

The Codec Support dataset is the first public, empirical dataset with hard numbers on codec support for AV1, HEVC, VP9, AVC and others for 1 million + devices. The dataset directly uses Device/Browser APIs to query codec decode/encode support from real user sessions of free.upscaler.video

Here are some of the most interesting findings from the data

Key findings:


AV1 Profile 0, 8-bit variants have reached ~91.5% decoder support across real-world sessions. That is a mainstream number.

The nuance is in who’s missing. Breaking down by browser and platform:

AV1 decode support by browser and platform

Two things stand out:

Safari is the genuine holdout. macOS Safari supports AV1 decode on only ~24% of sessions, iOS Safari on ~33%. This is the hardware gap — older Apple Silicon and all Intel Macs lack hardware AV1 decode, and Apple has not shipped a software decoder.

Firefox Android shows 0% — but this is a WebCodecs API gap, not an AV1 hardware problem. Firefox has not fully implemented the WebCodecs API on Android. The hardware on those devices almost certainly supports AV1; Firefox just doesn’t expose the API. This caveat applies throughout this analysis: Firefox Android numbers reflect API availability, not hardware capability.

For Chrome, Edge, and Firefox on desktop and Android, AV1 decode is effectively universal.


~88% of sessions support AV1 encoding — but only with the right codec string. The support landscape varies dramatically by profile and bit depth:

Profile Example Encoder Decoder
Profile 0, 8-bit (levels 4+)av01.0.16M.08~88%~91%
Profile 0, 8-bit (low levels)av01.0.00H.08~84%~88%
Profile 1, 8-bitav01.1.06H.08~79%~84%
Profile 0, 10-bitav01.0.18H.10~8%~91%
Profile 1, 10/12-bitav01.1.00H.100%~84%
Profile 2, all variantsav01.2.00M.080%~84%

For production AV1 encoding: use Profile 0, 8-bit only. Profile 1 drops to ~79%, and anything beyond that is effectively unsupported for encoding.

The 10-bit row deserves attention: decoder support stays at ~91% (the same as 8-bit), but encoder support falls to ~8%. The hardware can decode 10-bit AV1 — it just can’t encode it. This encode/decode asymmetry is not unique to AV1.


HEVC tells the inverse story of AV1. Where AV1 is universal on Chrome/Edge/Firefox and absent on Safari, HEVC is universal on Safari and nearly absent on Edge and Firefox:

HEVC decode support by browser and platform

The Edge number is particularly striking: Edge on Windows has much less decode support on Windows (56%) than the same engine that gives Chrome 81% on Windows. This appears to be a licensing issue — Microsoft does not always include HEVC decoding support in Edge.

For practical purposes: HEVC decoding works on Apple devices and Chrome on non-Windows platforms. It does not work on Edge or Firefox.


AV1 covers Chrome, Edge, and Firefox. HEVC covers Safari. The hypothesis that together they reach virtually everyone turns out to be correct.

From a confusion matrix across 958,110 sessions that tested both families:

AV1 + HEVC decode coverage stacked bar chart

AV1 + HEVC covers 99.73% of sessions for decode — above any reasonable threshold for universal coverage.

The 0.27% that support neither are likely very old hardware. H.264 covers them, but they represent a vanishingly small population.

For streaming and playback use cases, AV1 + HEVC is a complete modern codec strategy, without the need for fallbacks to older codecs like h264.


VP9 Profile 0 (8-bit) is frequently treated as a transitional codec — more modern than H.264, less modern than AV1. The data suggests a different view: VP9 is as universally supported as H.264 itself.

Codec Example Encoder Decoder
H.264 Baselineavc1.42002099.72%99.94%
VP9 Profile 0vp09.00.10.08.0099.99%99.99%
AV1 Profile 0, 8-bitav01.0.16M.0887.9%91.5%
HEVC Profile 1hvc1.1.6.L120.B073.8%85.1%

VP9 Profile 0 actually edges out H.264 Baseline for both encode and decode.

The confusion matrix confirms this: in the AV1 × VP9 comparison, AV1-only sessions (support AV1 but not VP9) = 0.00% (22 sessions out of 958,000). Essentially nobody supports AV1 without also supporting VP9. VP9 is a strict superset of AV1 support.

The same holds for H.264: AVC × VP9 shows 99.93% supporting both for decode, with near-zero supporting either alone.


The Encode/Decode Asymmetry: Strategy Depends on Use Case

Section titled “The Encode/Decode Asymmetry: Strategy Depends on Use Case”

This is where the streaming audience and the encoding pipeline audience diverge.

AV1 + HEVC covers 99.73% for decode — but only 98.16% for encode.

From the encoder confusion matrix (1,139,587 sessions):

AV1 + HEVC encode coverage stacked bar chart

The 1.84% gap — ~21,000 sessions — supports neither AV1 nor HEVC encoding. To close it:

Encoding strategy Coverage
AV1 only~88%
AV1 + HEVC98.16%
AV1 + VP999.91%
AV1 + AVC99.94%

If you’re building a streaming pipeline (decode): AV1 + HEVC gets you to 99.73%. You’re done. H.264 is a legacy safety net for the 0.27%.

If you’re building an encoding pipeline (WebCodecs transcoder, video editor, capture tool): AV1 + HEVC isn’t sufficient. You need AVC or VP9 as your encoding safety net. Both are effectively universal for encoding — pick one.


Audio: Only Opus and AAC Matter for Encoding

Section titled “Audio: Only Opus and AAC Matter for Encoding”

Audio is likely less relevant than video codecs, however there is nuance. For decode, AAC and Opus are pretty much universally supported, as are alternate codecs like PCM, Vorbis and FLAC.

For the WebCodecs api specifically, only Opus and AAC are well supported, however as audio codecs typically don’t require hardware acceleration, support can be added in for CPU based audio encode for any platform.

Codec Example Encoder Decoder
Opusopus96%96%
AACmp4a.40.290%96%
PCM variantspcm-u8~8%~94%
Vorbisvorbis~4%96%
FLACflac0%96%
MP3mp30%96%

Opus encoder support by browser and platform

AAC encoder support by browser and platform

Grey/yellow stripes (Safari): AudioEncoder API not available on older Safari versions — current Safari supports both codecs fine. Grey/green stripes (Firefox Android): WebCodecs API not available on Firefox Android.

FLAC and MP3 have essentially universal decoder support but zero encoder support via WebCodecs. If your pipeline needs to produce MP3 or FLAC output, you’ll need a WebAssembly encoder.


All data in this analysis comes from the Codec Support Dataset — 363,330,358 individual codec tests from 1,142,586 anonymous real-world user sessions of free.upscaler.video, collected January–March 2026.

This is WebCodecs data

Keep in mind that this dataset specifically uses queries from the WebCodecs API which has its own quirks. It seems safe to conclude that if decode/encode is supported by the WebCodecs API, that it is also supported by the device, however there may be codecs supported by the device not supported by the WebCodecs API, so these numbers are inherently conservative.

Sessions, not devices

All numbers (like 91.5% decode support) are based on device-sessions, which is reflective of real-world traffic to the specific application free.upscaler.video, but which may not be reflective of traffic for another application. Here is the traffic distribution for this data set:

Traffic distribution

A different application would likely have a different traffic distribution, however you are more than welcome to download the dataset yourself and weight codec support based on your own application’s traffic distribution.

Also, the dataset prevents the same device from being counted twice by using an in-browser localstorage uuid identifier, however a user on the same device with private / incognito mode (or the same device with different browsers) would count as seperate entries in the dataset.

Chromium

Due to the plethora of Chromium based browsers (Google Chrome, Edge, Brave, Opera, Perplexity etc..), all the Chromium based browsers are bundled together. The only exception is Edge, as (1) it exposes Edge as an identifier in the user agent string unlike most other Chromium browsers, (2) Edge is by far the most popular Chromium browser after Google Chrome. Perhaps in version 2 of the dataset I will track other chromium based browsers specifically, but from a developer standpoint regarding codec support it is unlikely to matter much.

A note on aggregate numbers

Codec family aggregate numbers can be misleading. When you see “AV1: 20% encoder support,” that averages across all 432 AV1 codec string variants — including 10-bit and 12-bit profiles that essentially no browser can encode. Throughout this analysis, support numbers refer to well-supported representative codec strings (Profile 0, 8-bit for AV1; Profile 1 Main tier for HEVC; Profile 0 8-bit for VP9; Baseline for H.264), not family-wide averages.

You can find a full detailed explanation of methodology here

Full dataset available on Zenodo and Hugging Face under CC-BY 4.0.

Browse the full codec registry →

The data comes from a live application I run. I will soon begin work on version 2 of this dataset with:

  • Hardware level codec support from native APIs on mobile (Android, iOS)
  • Capturing richer information on GPU such as vendor name / GPU class.

I want to make this dataset as useful for developers, industry experts and academics in video streaming space. If you have feedback or would like to request something specific for the next version of the dataset, feel free to reach out at sam@webcodecsfundamentals.org.

If you want to know when the next version of the dataset is released, you can register to be notified here, or just email me.