WebP vs JPEG vs... x264?! A Still Image Compression Comparison

Note: I originally made this comparison in 2013, and promptly forgot about it until mid-2017, when I decided to publish it here. I am fairly certain that progress has been made with both x264 and WebP's encoders since then, and will write up another comparison when I have the time.

JPEG has had incredible staying power as an image compression format. Originally ratified as a standard in 1992, JPEG saw widespread use across the world wide web, as early internet connections were low-bandwidth and loading webpages could take over a minute. As technology has progressed, formats for other forms of compression (generic data, video, and audio) have improved, but the compression of JPEG has been "good enough" that people only started to make efforts to replace it in the late 2000s.

One of the main contenders for dethroning JPEG, WebP, is now taking off, with Chrome now supporting decoding of .webp files natively. WebP is based upon the video codec VP8, which is commonly used in the .webm container for internet video.

A few years ago, Dark_Shikari (one of the main developers of x264) made a blog post comparing WebP to x264 frames, and determined that x264 was more suitable as an image format. Unfortunately that blog is no longer accessible, although you can view an archived version here thanks to the efforts of the archive.org team.

WebP as a format hasn't changed since then, but the encoder has had a lot of development put into it - Dark_Shikari was actually using libvpx, the vp8 video codec compression library, to encode single video frames as still images. Since then, Google has released a purpose-built WebP encoder and decoder, and several browsers support decoding .webp files natively.

Let's see how JPEG and WebP stack up against each other in 2013... and we'll throw in x264 intra frames for good measure, too.

Encoders used

For WebP, I used google's libwebp encoder (version 0.3.1), available from the official site. This is the most "official" encoder out there, as the WebP standard is being pushed by google themselves.

For JPEG, I used ffmpeg's encoder, version ffmpeg-201307220-git-419a3d8-win64-static, from here. To shrink the JPEG images further, I used the jpegtran utility from the libjpeg library..

For x264, I used r2345 of the official builds available from the videolan website here.

Image sources used

I used 9 frames from the test video sequences made available by the Xiph Foundation, available here. These are a mix of live-action and computer-generated animation.


I encoded the JPEG images first, using -q:v 8, then reduced the resulting images with jpegtran. This gave a target filesize to aim for with the other encoders.I then used the --crf option in x264 and the -q option in libwebp to find compression ratios that would match the JPEG images as closely as possible. eventually I was able to get within ~3kB of each file's size..

Finally, all images were losslessly transcoded to PNG for comparison purposes, using ffmpeg.


Filename source PNG filesize (bytes) JPEG filesize (bytes) WebP filesize (bytes) x264 filesize (bytes)
bbb_00195 2,677,877 226,235 226,960 226,145
bbb_00348 3,284,364 273,206 272,870 272,144
bbb_00972 2,594,161 180,676 178,562 179,963
bbb_03003 2,271,101 127,482 127,336 126,655
ED-01532 1,920,912 137,212 136,248 136,911
ED-02269 2,156,938 175,990 173,400 174,956
ED-07529 2,414,370 135,446 131,324 135,308
ED-09418 2,622,218 198,443 194,678 198,567
parkjoy-200 4,171,164 409,926 406,024 409,164

Note: it appears that both the x264 and webp images have had their brightness levels affected by a colorspace conversion somewhere. However this should not affect the amount of detail shown in the images. In future comparisons I hope to fix this issue.


While JPEG offers huge compression gains when compared to the lossless compression of PNG, it still falls far behind the more modern encoders in x264 and webp. blocking can be seen on gradients, and mosquito noise near sharp edges. Fine details in the background are sacrificed to save bits. Overall, it's acceptable, but we can do better.

WebP offers a much smoother final product, with much less blocking, and greater background detail. some noise is present.

x264 also offers more detail than JPEG, while introducing some grainy mosquito noise, most likely a byproduct of psy-rd. Fine details are preserved, and there is a small amount of blocking.


WebP is still in its infancy as a compression format. There will be more improvements to make as development continues. However it is already clear that the format offers significant gains over JPEG, and as support for the format improves in browsers and other applications, I hope we can switch to WebP as a new format.

As for x264, it is an interesting comparison, even if it's not that likely to be supported as a still-image format in the future. Hopefully, the competition will become strong in the future, as having just one format for compression will stifle innovation.