2010: A Codec in Search of a Market
The story of WebP doesn't begin in an image-editing department but in a video-codec lab. In August 2009, Google had acquired On2 Technologies for 124 million dollars — a codec specialist from Clifton Park, New York, best known for its VPx codec family (VP3, VP6, VP7). The real driver behind the purchase was VP8: a then brand-new video codec that could compete with H.264 and that Google wanted to have license-free for delivering YouTube.
In May 2010, Google released the acquired VP8 as an open-source specification and founded the WebM project for video delivery. In the same breath, Google engineer Jyrki Alakuijala demonstrated that VP8's intraframe compression (that is, the compression of individual frames without motion vectors) could also be used for still images. The result was called WebP and was released as an image format on September 30, 2010 — five months after VP8 went public.
The Technical Core: VP8 Intraframes
At its heart, lossy WebP uses the same algorithms as a single video frame in VP8. The image is broken into 16×16-pixel macroblocks, predictive coding estimates pixel values from neighboring blocks, the difference is quantized via a DCT (analogous to JPEG), and an arithmetic coder packs the residual data. Unlike JPEG's Huffman coding, arithmetic coding allows finer bit allocation, which at comparable quality typically yields files 25–35% smaller.
This kinship with a video codec is at once WebP's strength and its limitation. Strength: video codecs have to be extremely efficient per bit, because otherwise 30 frames per second wouldn't survive any bandwidth — that efficiency is now available to still images. Limitation: 16×16 macroblocks are designed for live scenes, not for diagrams or pixel art; with that kind of content the efficiency gains are smaller and PNG retains the edge.
2011: The Lossless Mode
A year after launch, Google added a lossless mode — one that had nothing more to do with the original VP8 pipeline. WebP Lossless is a completely separate specification, designed by Jyrki Alakuijala and Vincent Rabaud, based on predictive coding with larger blocks, a color transform, and an LZ77-style compression. The result: on graphics, files typically 20–40% smaller than optimized PNG.
This made WebP the first popular image format to offer both lossy and lossless compression in a single file container — a concept that AVIF and JPEG XL later adopted. There's a detailed analysis of this in our PNG vs. WebP comparison.
2012–2014: The Browser-Adoption Drought
Despite its technical advantages, little happened between 2012 and 2014. Chrome and Opera supported WebP from the start — both Google relatives. But Firefox, Safari, Internet Explorer, and Edgerefused to implement it. The reasons were partly technical (they wanted to wait until the format had stabilized) and partly political (Apple and Microsoft had no interest in legitimizing Google's format initiatives).
The paradoxical consequence: web developers had to ship a format that only some of their visitors could see. The <picture> tag, officially available as an HTML standard since 2014, became mandatory technique for anyone using WebP: first specify the WebP source, then a JPG fallback for the other 50% of browsers.
2016: Animation and Alpha
In 2016, Google extended WebP with two important features. Animationturned WebP into a direct GIF competitor, with markedly better characteristics: 24-bit color depth instead of 8-bit, true per-pixel alpha transparency, and interframe coding (only the pixels that changed between frames are stored). A typical 5 MB GIF becomes a 1.2 MB animated WebP — same animation, better quality, a quarter of the bytes. You'll find the full head-to-head in our GIF vs. WebP article.
Alpha in lossy mode was the second extension: previously only lossless WebPs could carry transparency; afterwards lossy WebPs could store alpha pixels too, with their own bit budget for the alpha channel. This made WebP the only file container that could replace both JPG (lossy photo mode) and PNG (lossless graphics mode) at the same time.
2018–2020: The Last Browsers Fall
Firefox implemented WebP in early 2019. Edge had already switched fully to Chromium by 2020, so it was on board. The decisive step came in September 2020: Safari 14 (macOS Big Sur, iOS 14) shipped native WebP support for the first time. With that, exactly a decade in, WebP had arrived in every relevant browser — and could be served without any fallback logic.
The Caniuse statistics showed over 95% browser coverage for the first time in 2021. From that point on at the latest, it was best practice to serve new web images primarily as WebP and to keep JPG only as an optional fallback for extremely old systems.
libwebp and the 2023 Security Hole
As with every dominant image decoder, WebP had its security scandal. In September 2023, CVE-2023-4863 went public — a heap buffer overflow in libwebp that allowed remote code execution. Because libwebp sits in practically every modern system (Chrome, Firefox, Safari, Electron, iOS, macOS, Android), it was one of the broadest single-library patch rollouts in recent internet history. Within days, updates appeared for all mainstream browsers; Citizen Lab documented that the flaw had been actively exploited in Israeli spyware.
Browser vendors learned a pragmatic lesson from the incident: image decoders belong in sandboxes. Chrome had already done this earlier; Firefox and Safari followed in 2024 with consistent process isolation for decoder libraries.
WebP in 2026: A Standard, but Not the Last Word
Today WebP is the pragmatic standard for web images. It's supported by every browser, every CMS platform serves it automatically, and smartphone galleries can read and write it. But AVIF and JPEG XL are pressing forward. AVIF (see our AVIF article) delivers files another 20–30% smaller, and JPEG XL has structural advantages for archives and progressive loading.
For now, WebP remains the “safe default” — robust implementations, ubiquitous hardware acceleration, clear efficiency gains over JPG. Our WebP compressoruses libwebp via WebAssembly locally in the browser; there's more background on encoder tuning in the big WebP guide.
When WebP Is the Right Choice
- Web delivery to the broad market. 97% browser coverage, clear byte savings over JPG/PNG.
- UI sprites with transparency. WebP Lossless replaces PNG with files 20–40% smaller.
- Animations instead of GIF. Three to four times the byte savings at better quality.
- E-commerce product photos. Faster page load, better Lighthouse score; see E-commerce optimization.
When WebP is notideal: print workflows (print shops often accept only classic formats), maximum efficiency (AVIF and JPEG XL are smaller), and very old backup software that can't open WebP.
Sources
Google Developers — WebP specification · RFC 6386 — VP8 Data Format and Decoding Guide · RFC 9649 — WebP Image Format · libwebp source code · CVE-2023-4863 — libwebp Heap Buffer Overflow · Can I Use — WebP browser support · Google Inc., “Lossless and Transparency Encoding in WebP,” 2011 (whitepaper).