H.264, HEVC, VP9, AV1: Which One Is in Your File

We encoded the same 1080p clip with all four codecs and scored the result against the original with VMAF. At a 1 Mbps target, AV1 lands 18 points ahead of H.264 and 4 points ahead of HEVC. At 4 Mbps, with each encoder's own default settings, HEVC comes out on top instead. Which one wins depends on the bitrate and the settings you feed it, not just the codec's reputation.

Pick a codec by what you need

• H.264 when the file has to open on the widest possible range of devices, software and years, at the cost of the largest files. Convert MOV to MP4 and FileFlip keeps H.264 video as H.264, a stream copy rather than a re-encode.
• HEVC when you're capturing or archiving on Apple hardware and storage matters more than universal compatibility.
• VP9 when the file is going on the web and you want royalty-free compression without AV1's encoding cost. Convert MP4 to WebM is the FileFlip route.
• AV1 when you control both ends, your own site or your own app, and can afford the encoding time its real advantage costs.

The four codecs at a glance

Which codec is actually in your file?

Almost always one of these four, whatever the extension says. An .mp4 or .mov usually holds H.264 or HEVC, a .webm holds VP9 or AV1, and an .mkv can hold any of the four, since Matroska places no limit on what goes inside. The extension only tells you the container, and MP4 alone can carry either compression level, so two .mp4 files can decode completely differently on the same phone. Codec vs container covers how to check with MediaInfo or ffprobe when you actually need to know.

Which codec compresses video the smallest?

AV1 at low bitrates, HEVC at high ones, in our test, and the ranking is closer than either format's reputation suggests.

We took a 10-second, 1920x1080 clip of Big Buck Bunny and encoded it four times at each of four bitrate targets, once per codec, then scored every result against the uncompressed source with VMAF, which is trained on human quality ratings rather than raw pixel error.

Read that table with a caveat attached: none of the four encoders hit the bitrate we asked for. libx264 and SVT-AV1 came in under it by 6 to 24%, libx265's rate control landed within 1%, and libvpx-vp9 ran 20 to 37% over on every row. Some of VP9's showing in that table is real efficiency and some of it is simply extra bits it spent without asking.

The bitrate ladder also hides AV1's real ceiling, because SVT-AV1 defaulted to its speed-8 preset. We re-ran the 2 Mbps point at preset 4, four times slower to encode, and it produced a file 17% smaller than HEVC's while matching its VMAF almost exactly, 86.50 against 86.42. AV1's compression advantage is real. It just doesn't show up until you spend the encoding time to unlock it, which is the "by whose measurement" problem with every codec comparison you'll read, including this one.

Which devices decode which codec in hardware?

H.264 decodes in hardware on essentially everything made in the last fifteen years. The other three arrived at different times and haven't caught up evenly.

As of August 2026, Android's own format support page is the primary source for the Android column, and Apple's HEIF/HEVC support page confirms the iOS 11 and macOS High Sierra cutoff for HEVC. A device missing a row's hardware decoder can usually still play the file in software, slower and at a real battery cost, which is the gap between "supported" and "supported well."

Why does codec licensing affect which one you should use?

Because two of these four codecs cost money to ship a decoder for, and manufacturers respond to that. H.264 and HEVC both sit behind patent pools that charge device makers and software vendors a royalty per unit; VP9 and AV1 were built specifically to avoid that.

The Wikipedia summary of MPEG LA's HEVC terms cites MPEG LA's own published rates; Access Advance's HEVC program page confirms a second, separate pool exists with its own terms. HEVC actually has a third pool, Velos Media, which most of the industry avoided one pool being confusing enough for. That fragmentation, not the codec's technical quality, is the reason plenty of hardware and software still treats HEVC as optional a decade after it shipped. VP9's exemption traces back to a single 2013 agreement, published by the WebM Project, where Google and eleven other patent holders granted a permanent royalty-free cross-license covering VP8 and, by its own terms, VP9. AV1's exemption works the same way through AOMedia's patent license: every member grants every implementer, member or not, a perpetual, no-charge license in exchange for making the same grant back.

FileFlip's own conversions carry this same split. Converting into MP4 or WebM in your browser tries a hardware encoder through WebCodecs first, and if your browser exposes one for H.264, that's what you get. When it doesn't, the fallback is an LGPL build of FFmpeg, and an LGPL build has no license to produce H.264 or HEVC output at all. It falls back further, to MPEG-4 Part 2, VP8, VP9 or Theora instead, a limitation stated on the conversion page itself the moment it applies. Converting to WebM never hits that wall, because VP9 was free to license from the start.

Which codec should you pick for your file?

Pick by where the file is going, not by which codec measured smallest in a table.

Sending a file to someone else, attaching it to an email, or publishing it somewhere you don't control the player: H.264 in MP4. It's the only one of the four with zero compatibility risk, and that's worth more than the size difference on a file that's getting watched once. Recording or archiving on your own Apple hardware, where storage is the constraint and playback stays inside Apple's ecosystem: HEVC is the native choice and costs you nothing extra to use. Publishing video on a website you control: VP9 in WebM is the safe default, and AV1 is the better one if your encoding pipeline (or FileFlip's browser-based one) has the time to spend on a slower preset. None of these is the "right" answer in general. Deciding by the destination first, format second, is what avoids the debate entirely.

Common questions

Is HEVC the same thing as H.265?

Yes. HEVC is the name the standard is usually marketed under; H.265 is its ITU-T designation, the same numbering scheme that named H.264's predecessor. Every file, encoder and spec referring to either name means the identical codec.

Does AV1 always produce a smaller file than H.264?

Not automatically, and not from every encoder. Our own test shows H.264 catching up to AV1's default-preset output at higher bitrates, and AV1's advantage only fully appears once you give SVT-AV1 a slower preset than its default. The codec has more headroom than H.264; unlocking it costs encoding time.

Why does my iPhone record HEVC but some apps refuse to open the file?

Because HEVC support outside Apple's own software arrived unevenly. The Settings app has a Camera > Formats toggle: "High Efficiency" records HEVC and HEIC, "Most Compatible" switches to H.264 and JPEG for anything you're about to hand to older software. How to open HEIC files on Windows covers the same problem on the photo side, since HEIC uses HEVC's compression for still images.

Can renaming a file change which codec is inside it?

No. Renaming only changes the extension your player trusts; the encoded bytes underneath don't move. A .webm holding H.264 won't play just because you rename it to .mp4, and the reverse won't make an .mp4's HEVC stream playable on a device that only decodes H.264.

Convert between them

FileFlip converts MOV to MP4 and MP4 to WebM entirely in your browser. Nothing is uploaded, there's no account, and when the source codec already fits the target container, the conversion is a stream copy rather than a re-encode, the same distinction covered in codec vs container. The video converter handles every other pair, and the MP4, WebM and MKV format pages cover what each container can hold.

How we measured this

• Source clip: the same 10-second, 1920x1080, 30 fps Big Buck Bunny segment (Blender Foundation, CC BY 3.0) used across our video posts.
• Encoders: FFmpeg 8.1.2 on macOS, libx264 for H.264, libx265 for HEVC, libvpx-vp9 at -deadline good -cpu-used 2, and libsvtav1 for AV1, all at their default presets unless noted. The one preset-4 SVT-AV1 run is called out explicitly where it's used.
• Bitrate ladder: each encoder run four times per codec at -b:v targets of 0.5, 1, 2 and 4 Mbps, audio stripped so only the video stream is measured.
• Quality metric: FFmpeg's libvmaf filter, comparing each encode back to the uncompressed source after scaling both to the source resolution.
• Matched-size figure: H.264 at 0.5 Mbps and AV1 tuned to 0.53 Mbps, the closest pair we found within 2% of the same output size; frames pulled from the same timestamp, cropped to 256x150 and magnified 2x with ImageMagick.
• Caveat: one animated clip is a single data point, and the exact VMAF numbers will shift with different content, especially live-action footage with more motion and grain than a rendered short. The over/undershoot behavior against the requested bitrate is specific to these four encoder implementations at these settings, not a property of the codecs themselves; a different encoder for the same codec (Google's VP9 encoder tuned differently, or the reference libaom AV1 encoder instead of SVT-AV1) would land on different numbers again, which is the whole point of the "by whose measurement" heading above.