All these years the web ecosystem has been using a handful of image formats, all deeply flawed since they were conceived at the dawn of the web, while for fifteen years we’ve had access to the perfect one, combining everything we ever wanted.

WebP stands as proof that technical superiority alone isn’t enough to dethrone the competition and become the undisputed standard, even when there’s nothing to criticize and everything to gain by adopting it. It remains underappreciated, disliked (the first result in YouTube is “The Most HATED Image Format” video), even mocked. And just as people are beginning to recognize it for what it truly is, the go-to for almost every use case, a new format has emerged, trying to claim its piece of the web.

The first widely used formats on the World Wide Web were GIF (pronounced “jif,” as its creator insists), a relic still alive today, especially for memes and all kinds of cringe-worthy [and iconic] animations, and JPEG, both respectively created in 1987 and 1992.

Both format are very different: GIF is limited to 256 colors, with just one that can be transparent, and since its compression method is optimized for areas of flat color, photographs are its nemesis, leading to degraded hues and massive file sizes.

SpaceJam is still alive and remains a small pearl of web nostalgia. Enjoy the source code.

On the other hand, JPEG (or JPG, since Windows only accepted three-letter extensions at the time) offers a proper way to display photographs with thousands of colors and relatively efficient compression, though compressing too much would alter the image in ways any trained eye could spot. For a long time, this combination was the only option we had to display images on the web. GIF was used for logos, animations, clip art, and anything small enough to fit within a 256-color palette, often with transparency and sharp edges. JPEG became the de facto format for large images and photographs.

A few years later, in 1996, PNG became part of the W3C Recommendation as a partial alternative to GIF, but sadly, it took more than a decade to be fully supported. PNG offered an improved lossless compression format over GIF, with higher color depth and 256 levels of transparency instead of just one, although it was heavy and poorly suited for photographs. Animation was also left to other emerging formats like Macromedia Flash and the painfully slow effort to establish a common JavaScript standard across browsers.

And since then, it feels like nothing has really changed. If you browse the web today, you’ll still see mostly GIFs for memes and small animations (APNG never took off), JPEGs for pictures, and PNGs for logos and clip arts (except for the rise of SVG, thank god, but that’s for vector illustrations). We just stuck with it, even though it’s impractical af, since none of these formats are truly adequate.

The birth of WebP came from the video compression industry. It is, fundamentally, a still frame of the VP8 video codec repurposed as a static image format. In 2008, On2 Technologies developed this highly efficient block-based video codec competing with H.264. The company was acquired by Google in 2010 and decided to open-source VP8 to promote royalty-free multimedia formats.

The main difference with its predecessors, and what makes WebP stand out by its versatility, is the fact that WebP is not a monolithic format like its predecessors, it is a RIFF-based image format. If I lost you here, let’s rewind a bit.

GIFs, JPEGs, and PNGs are monolithic. Each relies on a single algorithm with its own strengths and weaknesses. A RIFF (for Resource Interchange File Format) is different, it’s a generic container format. If you’ve ever downloaded videos online (copyright free, of course), you’ve probably noticed that while the file had an extension like .AVI, you sometimes needed a specific codec to play it, unless you used VLC or IINA, which would make you a tech-savvy and sophisticated person (or it means you’ve never downloaded a video from the internet, in which case you’re a saint). In a way, WebP is like the AVI container that can host different codecs as long as they comply with its specifications.

Inside a WebP, you can have VP8 or VP8L for image data, ALPH for transparency, ANIM or ANMF for animation, and metadata chunks like EXIF, ICCP, and XMP. A structure allowing a single WebP file to handle animated, lossy or lossless images with transparency, combining the best features of other formats in one efficient and flexible standard.

Therefore, WebP delivers results that range from good to downright dramatic. For instance, converting my 1674×1674 UFO background image from PNG (as a lossless starting point) to JPEG (95% quality) and WebP (95% quality), I managed to shrink the 1.5 MB PNG file down to 470 KB as a JPEG and just 170 KB as a WebP.

This is, of course, an exceptional case: the image’s complex color gradients make it unsuitable for PNG compression, yet perfectly matched for WebP’s predictive algorithm. Overall, comprehensive benchmarks from Google show that WebP typically provides 25-34% better compression than JPEG and about 26% over PNG, while also offering solid gains compared to GIF for animations.

Some claim that state-of-the-art JPEG compression can rival WebP in certain cases. Probably true, but let’s be honest: there are probably a handful of people who actually know how to perform true SoTA JPEG compression.

As we stated earlier, WebP contains two main compression methods: VP8 (lossy, meaning it alters the image to reduce its weight) and VP8L (lossless).

Inherited from video compression research, the VP8 algorithm splits each frame into macroblocks (see Technical Overview of VP8: An Open-Source Video Codec for the Web, 2011). Each macroblock contains a 16x16 block for the luma (brightness or Y channel) and two corresponding 8x8 blocks for the chroma (color or U and V channels). These are further divided into 4×4 sub-blocks to enable more precise prediction and more efficient compression. Instead of storing the color of every pixel, it analyzes patterns and similarities between blocks and records only the changes. It then applies mathematical transformations to predict what each block should look like and stores only the differences. This approach makes it highly efficient, sometimes achieving exceptional results when prediction works particularly well.

VP8L, the lossless (meaning the image stays exactly the same) compression is more classic: it finds repeated patterns (like similar colors or shapes) and replaces them with short “codes,” kind of like shorthand, instead of repeating the same data over and over. It predicts what the next color or pixel will be based on its neighbors, so it only needs to save the difference if it’s wrong: this can save lots of space depending on the image. For simple images, it can use a “palette,” which means it just notes which colors are used and then describes the image in terms of those colors instead of specifying the RGB values for each pixel.

Mr. Monk says every gift comes with its curse, and WebP’s evolutionary traits come with a price. The format was officially released in 2010 with support from Chrome only in 2011. It offered poor visual quality, slow encoding, and no transparency, which made it useless for icons or overlays. Year after year, more features arrived in the toolbox, ALPH, VP8L, ANIM, and plagued by its complexity, the browsers adopted it slowly and painfully as the specifications were moving too much instead of implementing a closed and finished product. Opera added it in 2012, Firefox in 2019, and the most stubborn of all, Safari, meaning the iPhone, in 2020.

As mentioned, there were valid reasons for resistance during the early days: fuzzy specifications, but also unclear royalty status until 2013 (MPEG LA quickly argued that VP8 might infringe on some of their patents, and WebP’s lossy compression is based on VP8 key frame encoding), technical complexity, and slow encoding for instance. But the format stabilized and fixed all this around 2013 or 2014.

The decision for Chrome to release and enforce updates every six weeks was meant to speed up the adoption of new formats. As surreal as it sounds, back then Internet Explorer was updated every two to three years (a blessing for some 🏴‍☠️), Firefox every six to twelve months, and Safari tied its updates to macOS releases. Opera was faster, with roughly two updates a year, but nobody really used it anyway. With this policy, Chrome changed the landscape by either dominating it or forcing everyone else to keep pace, making the adoption cycle much faster, yet it never had the impact on WebP that you’d expect.

So it took forever. And here’s the kicker, that wasn’t even the end of it. Getting a format adopted isn’t just about browsers being able to display it, you have to convince the whole pipeline. It took another two years for Photoshop after Apple’s adoption to vaguely adopt WebP, WordPress, which powers around 40% of websites, only added support in 2021, and even today macOS Preview can only read WebP and suggests converting it to TIFF for editing. What an insult. Even worse, Figma, the most popular tool for web design, still doesn’t provide WebP export, only PNG, JPEG, SVG, and PDF.

Because of all this, WebP has been overlooked the whole time. Getting a WebP file and not being able to work with it without converting it first is infuriating, hence the WebP hate. It makes you hate the format when it’s actually the fault of the software makers. You might think it’s a pain to implement or that Google makes it difficult, but absolutely not, everything is right there on the page.

For Figma, the reason seems twofold. First, since it’s an Electron app running a custom C++ rendering engine compiled to a WebAssembly environment, it seems adding WebP support actually takes engineering work. Meanwhile, plugins for Figma run in a different environment with full browser access, which makes it easier for third parties to offer WebP export. And second, it feels like nobody’s asking for it, so it’s just not a priority. I am sadness.

I said before that WebP was filling all the gaps, but obviously nothing’s perfect in this world, and WebP doesn’t cover the full picture, even though the lack of support for HDR is only an issue for professionals.

In 2019, AVIF was released to be the perfect solution (read An evaluation of the next-generation imagecoding standard AVIF, 2020), and is actually quite there. Like WebP, AVIF is also born from video tech, built on the AV1 codec that was made for high compression efficiency in both still images and video frames.

Packed into a ISOBMFF container (same as MP4), it uses advanced intra-frame prediction, transform coding, and entropy coding to squeeze both natural and synthetic images efficiently. AVIF adds one more chroma subsampling option, giving finer control over color fidelity and compression, especially for videos, while also supporting high color accuracy, HDR, and Wide Color Gamut imagery.

👉 This article is too long for the newsletter, read the rest on WeLoveSota.com

No posts