Encode Once, Compare Three Video Formats on Your Own Footage

Every guide to video codecs will tell you one is more efficient than another. None of them can tell you what that means for your clip, because the answer depends on what is in it. The format comparison tool settles the argument by encoding the same video two ways, WebM VP8 and MP4 H.264, so you can compare actual file sizes instead of reasoning about codecs in the abstract.

A correction, 2026-09-11. This article previously described three encodes including WebM VP9, and the tool offered three. It does not any more. The WebAssembly build of ffmpeg this site ships cannot encode VP9: seven different encoder settings were run against it in a real browser, on a fresh core each time, and every one crashed after the first frame, while a VP8 control encoded the same clip normally in the same run. So the VP9 row was never producing a file for you to measure. The options were to ship a different ffmpeg build, to relabel a VP8 file as VP9, or to stop offering it. Relabelling would have reported a size for an encode that never happened, which is the worst of the three. VP9 is gone until there is a core that can actually produce it.

Why the general advice is not enough

Codec efficiency is usually quoted as a single number: some percentage better at equivalent quality. That number comes from averaging across a standard test set, and your video is not the average of a standard test set.

What actually drives the result:

Motion. A static talking head compresses enormously well in any codec, and the gap between codecs narrows because there is little to predict. A handheld shot of moving foliage is close to the worst case, and the gap widens.

Detail. Fine texture is expensive. Film grain, fabric, gravel, hair, and rain all cost bits in every codec and defeat the prediction that newer codecs are better at.

Cuts. Every hard cut forces a keyframe, and keyframes are large. A clip with a cut every second spends a lot of its budget on them.

Resolution and length. These scale everything, including how long you will wait.

Flat areas. Letterbox bars, a plain backdrop, a solid graphic. These are nearly free, which is why a padded clip costs less extra than you would expect.

A tool that measures your clip answers the question the averages cannot.

Read the result as a ratio, not as three numbers

The absolute sizes matter less than the relationships between them.

H.264 smaller than VP8. The usual outcome. VP8 is the older codec of the two, and H.264 at CRF 23 is a strong default.

VP8 close to H.264. Your content is simple enough (low motion, flat areas, short) that the codec choice barely matters, and compatibility should decide it.

VP8 smaller than H.264. Uncommon, and worth a second look at what was actually compared before acting on it. It happens most often on synthetic content with large flat regions.

The decision here is not really about size. VP8 exists in this tool because it is an open format with no licensing question attached, and because it plays in places that want WebM. If you need the smallest file that plays everywhere, that is H.264.

Size is not quality, and this is the trap

Two files at two sizes are not automatically ranked by the smallest being best. A smaller file can be smaller because the encoder discarded more.

So compare the pictures, not only the numbers. Look at the parts of the frame that reveal compression first:

• edges of text and graphics, where blocking and ringing show up
• smooth gradients such as sky or a studio backdrop, where banding appears
• fast motion, where detail turns to mush for a few frames
• anything with fine texture, which is the first thing an encoder gives up

If a smaller file looks the same at full size on a real screen, take it. If the saving came out of the quality, you have not saved anything, you have moved the cost.

Test with a representative clip, not the whole video

You do not need to encode a twenty minute video twice to learn which codec suits it. That is two long encodes to answer one question.

Take a short section that represents the hardest part: the busiest motion, the most detail, the cuts. Compare on that. The ratios hold, and you get the answer in a fraction of the time.

Testing on the easiest thirty seconds is the common mistake. Every codec looks good on a static shot, so the comparison tells you nothing about the section that will actually break.

What this tool is not for

Choosing a quality level. This compares formats. Tuning quality within one is what the compressor is for.

Producing the final file. Once you have decided, use the format converter, from your original source. Do not adopt one of the comparison outputs as a master if it was produced for measurement.

Deciding whether to convert at all. If the file already plays everywhere it needs to and the size is acceptable, there is nothing to fix. Re-encoding always costs a generation of quality, so a conversion needs a reason.

Nothing is uploaded

Both encodes run on your device. That has a cost and a benefit, and both are honest: the benefit is that your footage never leaves the browser, and the cost is that you are paying for the encodes with your own hardware and can feel it.

This is exactly why the short representative clip is the right technique rather than a shortcut. It gets the same answer for a fraction of the work.

A short method

1. Cut a short section containing the hardest content in the video.
2. Encode it both ways and read the ratio rather than the raw sizes.
3. Compare the pictures at full size, looking at text edges, gradients and fast motion.
4. If the sizes are close, choose H.264 for compatibility.
5. If WebM VP8 is smaller and looks the same, choose it, provided you control where the file is played.
6. Produce the final file from the original source with the converter, not from the comparison output.