The Codec Your Browser Picked, and Why It Was Not Your Choice
SnapFrom Team · · 4 min read
Two people open the same video page on the same site at the same moment. One of them is served AV1. The other is served H.264, at a larger file size, for the same picture. Neither was asked, and neither is told.
This is not a rare edge case. It is the normal operation of a mechanism the web has had for years, and the interesting part is how little the browser will actually commit to when asked.
The browser refuses to promise
The oldest way to ask is canPlayType(), and it answers with one of three strings: the empty string, "maybe", or "probably"[1].
Read those again. The best available answer is “probably”. There is no “yes”.
The empty string means the media cannot be played on this device. "probably" means it probably can. "maybe" means there is not enough information to determine whether it can play until playback is actually attempted[1]. Ask about plain video/mp4 with no codec specified and you get "maybe", because an MP4 container tells you almost nothing about what is inside it[1].
A specification that returns “probably” as its confident case is telling you something real: support is not a property of the browser alone. It depends on the operating system, the hardware, and what the device will actually do at runtime.
The newer question is more honest
MediaCapabilities.decodingInfo() splits the question into three, and the split is the useful part. It resolves to an object where supported is true if the content can be decoded at all, smooth is true if playback can hit the configured frame rate without dropping frames, and powerEfficient is true if playback will be power efficient[2].
Those are three genuinely different failures. A device can decode a codec, and drop frames doing it. A device can decode it smoothly, and empty the battery doing it, because the work is happening in software on the CPU instead of in a dedicated decode block.
There is a caveat in the documentation that matters more than it looks: browsers “will report a supported media configuration as smooth and powerEfficient until stats on this device have been recorded”[2]. The first answer a page gets on a fresh profile is optimistic by default. The honest answer arrives later, after the device has actually tried.
What is being chosen between
The practical fork today is AV1 against H.264, and they are not two flavours of the same thing.
AV1 is royalty-free and reaches as much as 50% higher compression rates than AVC[3]. That is a large number in the right direction: the same picture in roughly half the bytes.
H.264 is the opposite trade. It is a proprietary format requiring a license for commercial use, though the Via LA pool charges no fee for internet video that is free to end users, and it plays on every version of Chrome, Edge, Firefox, Opera and Safari with broad hardware encode and decode support[3].
So the site’s choice is between a format that costs the viewer half the bandwidth and one that is certain to work.
Where the split actually falls
AV1 is supported in all browsers, with one condition that quietly does most of the work: support in Safari “is limited to devices that feature a hardware decoder, meaning M3 MacBooks and later, iPhone 15 Pro, and iPhone 16 and later”[3].
That single line explains the two-people-one-page case. On Apple hardware, AV1 is not a browser-version question, it is a silicon question. A perfectly current iPhone that happens not to be one of the listed models will be handed H.264, and there is nothing the user can do about it, because the missing piece is a decode block that is not in the chip.
This is also why “does my browser support AV1” is the wrong question to ask a compatibility table. The table answers for the engine. The engine answers for the device.
What it costs you
Bandwidth, if you are on the wrong side of the split. Up to twice the bytes for the same picture[3], on a connection you may be paying for by the gigabyte.
Battery, invisibly. powerEfficient exists as a separate boolean from smooth precisely because a video can play perfectly and still be decoded in software[2]. Nothing in the interface tells you which one you got. The tell is thermal, not visual.
A decision made from stale information. Because the first decodingInfo() answers default to optimistic until the device has recorded stats[2], the first video you play in a fresh profile can be picked on an assumption rather than a measurement.
None of this is a fault in the browsers. Codec support is genuinely a hardware property, and the APIs are unusually candid about not knowing. It is worth understanding mostly because it is the answer to a question people ask constantly and get wrong: no, the video is not “the same for everyone”, and the difference is not on the server.
Sources
- HTMLMediaElement: canPlayType() method
- MDN Web Docs, Mozilla, accessed
Supports: canPlayType() returns one of exactly three strings: the empty string, meaning the media cannot be played on the current device; 'probably', meaning the media is probably playable; and 'maybe', meaning there is not enough information to determine whether it can play until playback is actually attempted. Calling it on 'video/mp4' with no codecs parameter returns 'maybe'.
- MediaCapabilities: decodingInfo() method
- MDN Web Docs, Mozilla, accessed
Supports: decodingInfo() resolves to an object carrying three booleans: 'supported' is true if the content can be decoded at all, 'smooth' is true if playback can hit the configured frame rate without dropping frames, and 'powerEfficient' is true if playback will be power efficient. MDN records the caveat that browsers 'will report a supported media configuration as smooth and powerEfficient until stats on this device have been recorded', and that all supported audio codecs report powerEfficient as true.
- Web video codec guide
- MDN Web Docs, Mozilla, accessed
Supports: AV1 is 'fully royalty-free' and achieves 'as much as 50% higher' compression rates than AVC. It is supported in all browsers, but 'support in Safari is limited to devices that feature a hardware decoder, meaning M3 MacBooks and later, iPhone 15 Pro, and iPhone 16 and later'. AVC by contrast 'is a proprietary format' whose commercial use requires a license, though the Via LA patent pool charges no fee for streaming internet video in AVC as long as the video is free for end users, and it is supported by all versions of Chrome, Edge, Firefox, Opera and Safari with broad hardware encode and decode support.