Hubbry Logo
WebPWebPMain
Open search
WebP
Community hub
WebP
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
WebP
WebP
WebP
View on Wikipedia
from Wikipedia

WebP
The Wikipedia logo, as a WebP file
Filename extension
.webp[1]
Internet media typeimage/webp[2]
Uniform Type Identifier (UTI)org.webmproject.webp[3]
Magic number52 49 46 46 xx xx xx xx 57 45 42 50 56 50 38[4]
Developed byGoogle
Initial release30 September 2010; 15 years ago (2010-09-30)[5]
Type of formatImage file format with lossless and lossy compression
Contained byResource Interchange File Format (RIFF)[6]
StandardRFC 9649
Open format?Yes[7]
Free format?Yes
Websitedevelopers.google.com/speed/webp
libwebp
DeveloperGoogle
Stable release
1.6.0[8] Edit this on Wikidata / 9 July 2025; 3 months ago (9 July 2025)
Repositorychromium.googlesource.com/webm/libwebp
Written inC
TypeDigital imaging
LicenseBSD license
Websitedevelopers.google.com/speed/webp

WebP is a raster graphics file format developed by Google intended as a replacement for JPEG, PNG, and GIF file formats. It supports both lossy and lossless compression,[9] as well as animation and alpha transparency.

Google announced the WebP format in September 2010; the company released the first stable version of its supporting library in April 2018. WebP has seen widespread adoption across the Internet in order to reduce image size, with all major browsers currently supporting the format. However, critics have questioned whether it offers tangible speed benefits, and cited its lack of compatibility with older software and use as a replacement for JPEG or PNG source files as making the format user-unfriendly for those who download and save images, often requiring a time-consuming conversion process.

History

[edit]

WebP was first announced by Google on 30 September 2010 as a new open format for lossy compressed true-color graphics on the web, producing files that were smaller than JPEG files for comparable image quality.[10] It was based on technology which Google had acquired with the purchase of On2 Technologies.[11] As a derivative of the VP8 video format, it is a sister project to the WebM multimedia container format.[12] WebP-related software is released under a BSD free software license.[13]

On 3 October 2011,[14] Google added an "Extended File Format"[15] allowing WebP support for animation, ICC profile, XMP and Exif metadata, and tiling (compositing very large images from maximum 16384 × 16384 tiles). Tiling support was never finalized and was removed from the spec again.[16] Older animated GIF files can be converted to animated WebP.[citation needed]

On 18 November 2011, Google announced a new lossless compression mode, and support for transparency (alpha channel) in both lossless and lossy modes; support was enabled by default in libwebp 0.2.0 (16 August 2012).[17][18] According to Google's measurements in November 2011, a conversion from PNG to WebP resulted in a 45% reduction in file size when starting with PNGs found on the web, and a 28% reduction compared to PNGs that are recompressed with pngcrush and PNGOUT.[19]

In July 2016, Apple added WebP support to early beta versions of macOS Sierra and iOS 10,[20] but support was later removed in the GM seed versions of iOS 10 and macOS Sierra released in September 2016. In September 2020, WebP support was added in Safari version 14.[21]

The supporting libwebp library reached version 1.0 in April 2018.[22]

As of 2024, web browsers that support WebP had 97% market share.[23]

In November 2024, WebP was formally specified in and published as RFC 9649.

Technology

[edit]
Simple WebP
Bytes Content
0–3 R I F F
4–7 length + 12
8–11 W E B P
12–15 V P 8 (space)[24]
16–19 length (padded)
20–… VP8 key frame
pad ? (even length)

WebP's lossy compression algorithm is based on the intra-frame coding of the VP8 video format[25] and the Resource Interchange File Format (RIFF) as a container format.[5] As such, it is a block-based transformation scheme with eight bits of color depth and a luminance–chrominance model with chroma subsampling by a ratio of 1:2 (YCbCr 4:2:0).[26] Without further content, the mandatory RIFF container has an overhead of only twenty bytes, though it can also hold additional metadata.[5] The side length of WebP images is limited to 16383 pixels.[7]

WebP is based on block prediction. Each block is predicted on the values from the three blocks above it and from one block to the left of it (block decoding is done in raster-scan order: left to right and top to bottom). There are four basic modes of block prediction: horizontal, vertical, DC (one color), and TrueMotion. Mispredicted data and non-predicted blocks are compressed in a 4×4 pixel sub-block with a discrete cosine transform or a Walsh–Hadamard transform. Both transforms are done with fixed-point arithmetic to avoid rounding errors. The output is compressed with entropy encoding.[26] WebP also has explicit support for parallel decoding.[26]

The reference implementation consists of converter software in the form of a command-line program for Linux (cwebp) and a programming library for the decoding, the same as for WebM. The open-source community ported the converter to other platforms, such as Windows.[27]

The WebP container (i.e., RIFF container for WebP) allows feature support over and above the basic use case of WebP (i.e., a file containing a single image encoded as a VP8 key frame). The WebP container provides additional support for:

Metadata
An image may have metadata stored in Exif or XMP formats.
Transparency
An image may have transparency, i.e., an alpha channel.
Color profile
An image may have an embedded ICC profile as described by the International Color Consortium.

Lossless compression

[edit]

WebP's lossless compression, a newer algorithm unrelated to VP8, was designed by Google software engineer Jyrki Alakuijala. It uses advanced techniques such as dedicated entropy codes for different color channels, exploiting 2D locality of backward reference distances and a color cache of recently used colors. This complements basic techniques such as dictionary coding, Huffman coding and color indexing transform.[17] This format uses a recursive definition: all of the control images, such as the local entropy code selection, are encoded the same way as the whole image itself.[28]

Animation

[edit]

Google has proposed using WebP for animated images as an alternative to the popular GIF format, citing the advantages of 24-bit color with transparency, combining frames with lossy and lossless compression in the same animation, and support for seeking to specific frames.[29] Google reports a 64% reduction in file size for images converted from animated GIFs to lossy WebP, however, with a very noticeable visual impact, both at default settings, and optimised settings. When converting using lossless WebP, a 19% reduction is achieved as reported by Google,[29] although real-world performance is nearer to 10%.[30]

Support

[edit]

Web browsers

[edit]

Google actively promotes WebP, and Google Chrome and all Chromium-based browsers support the format. The proprietary PageSpeed Insights tool suggests that webmasters switch from JPEG and PNG to WebP in order to improve their website speed score.[31]

Microsoft Edge versions released after January 2020 are based on the Chromium browser, and have native WebP support. EdgeHTML-based versions of Microsoft Edge support WebP through a platform extension (installed by default) (unless running in the security-hardened "Application Guard" mode, which does not support platform extensions).[32]

Safari added support for WebP in 2020 with iOS 14 and macOS Big Sur.[21]

Mozilla Firefox[33] officially supports WebP since January 2019.[34] It was initially considered for implementation in 2013.[35]

Pale Moon implemented initial support for WebP in 2016 with its version 26 milestone.[36]

SeaMonkey began supporting WebP with its version 2.53.5 released in November 2020.[37]

GNOME Web, Midori, and Falkon natively support WebP.

WebP can also be displayed in all major browsers using the WebPJS JavaScript library, although support in Internet Explorer 6 and above is achieved using Flash.[38]

Support for WebP was added to Links in version 2.26.[39]

Graphics software

[edit]

After WebP was announced in September 2010, software gradually began to support it. By 2011, there were plugins for several popular graphics software programs to support WebP, and some programs such as Acorn and Pixelmator had added native support.[40] Over time, support for the WebP format has grown.

Software First version with native support Release date of native support Notes Reference
Pixelmator Classic 1.6.2 6 October 2010 [41][42]
Acorn 2.6 21 October 2010 Export of lossless WebP added in 2022[43] [44]
ImageMagick 6.6.8-5 14 March 2011 [45][46]
GraphicConverter 7.2 8 April 2011 [47]
XnView 1.98 9 May 2011 [48]
PaintShop Pro X4 (14.0) 7 September 2011 [49][50][51]
Picasa 3.9 8 December 2011 [52]
IrfanView 4.32 15 December 2011 [53]
GDAL 1.9.0 9 January 2012 [54][55]
gThumb 3.1.1 23 September 2012 [56]
PhotoLine 18 4 October 2013 [57][58]
Canvas X 15 20 November 2013 [59][60]
Krita 2.9.5 10 June 2015 Basic support [61]
5.1.0 18 August 2022 Full support [62][63]
Aseprite 1.1.1 6 November 2015 [64]
Sketch 41 8 November 2016 [65]
GIMP 2.10 27 April 2018 [66][67]
Paint.NET 4.2.5 1 October 2019 [68]
Pixelmator Pro 1.6.4 4 June 2020 [69]
Inkscape 1.1 24 May 2021 Export only [70]
Xara Designer Pro+ 18.5 24 August 2021 [71]
Adobe Illustrator 26.0 16 October 2021 [72][73]
Adobe Photoshop 23.2 17 February 2022 [74][75]
Blender 3.2 8 June 2022 [76][77]
LibreOffice Draw 7.4 18 August 2022 [78]
Affinity Designer 2.0 9 November 2022 [79][80]
Shotwell 0.32.0 23 April 2023 [81]
Windows Photos 2023.11050.2013.0 3 May 2023 [82][83]
CorelDRAW 24.5 18 September 2023 [84]
Clip Studio Paint 3.0.0 14 March 2024 [85]
PhotoMill 2.8.0 11 November 2024 [86]

In 2019, Google released a free plug-in that enables WebP support in earlier versions of Adobe Photoshop.[87] Free Photoshop plug-ins had been released by Telegraphics and fnordware before that.[88][89] GIMP up to version 2.8 also supported WebP via a plugin;[90] later, this plugin was shipped in GIMP 2.9 branch, and received multiple improvements.[91] Google has also released a plug-in for Microsoft Windows that enables WebP support in Windows Photo Viewer, Microsoft Office 2010, FastPictureViewer,[92] and any other application that uses Windows Imaging Component.[93]

Other programs

[edit]

FFmpeg linked with the VP8/VP9 reference codec library libvpx can extract VP8 key frames from WebM media and a script can then add the WebP RIFF header and the NUL pad byte for odd frame lengths. Meanwhile, FFmpeg supports libwebp directly.

Gmail and Google Photos both support WebP. Support for WebP is also planned for Google App Engine. The Instant Previews feature of Google Search uses WebP internally to reduce disk space used by previews.[94] Android 4.0 supports encoding and decoding WebP images (via bitmap and Skia).[95] SDL_image supports the format since 1.2.11.

Sumatra PDF supports WebP images for both standalone files and comic books since version 2.4.[96]

Telegram Messenger uses WebP for its Stickers, claiming they are displayed five times faster compared to the other formats usually used in messaging apps.[97]

Signal uses WebP for its non-animated stickers.[98]

LibreOffice supports the import of WebP images since version 7.4,[99] so does the LibreOffice technology based online office Collabora Online.

Godot Engine as of version 4.0 supports importing and exporting WebP images and uses WebP as its internal format for storing imported compressed textures.[100]

Content management systems (CMS) usually do not support WebP natively or by default. However, for most popular CMS, extensions are available for automated conversion from other image formats to WebP and delivering WebP images to compatible browsers. Since June 2021, WordPress supports WebP natively.[101]

Social media services known to natively support WebP in messages include Facebook,[102] Slack,[103] Discord[104] and Element;[citation needed] however, some of these services only support static WebP, and not animated WebP.[citation needed]

Disadvantages and criticism

[edit]

Like VP8 on which it is based, lossy WebP supports only 8-bit YUV 4:2:0 format,[105] which may cause color loss on images with thin contrast elements (such as in pixel art and computer graphics) and ghosting in anaglyph. Lossless WebP supports VP8L encoding that works exclusively with 8-bit RGBA (red, green, blue, alpha) color space.[106][107] It has no support for 10-bit color depth, while the successors HEIC and AVIF added 10-bit color depth support.

Due to the complexity of their compression method, WebP files take significantly more time to create than other web image formats. It is therefore usually not advisable to process WebP images on demand, as is the case with Web Map Services.[108]

In September 2010, Fiona Glaser, a developer of the x264 encoder, wrote a very early critique of WebP. Comparing different encodings (JPEG, x264, and WebP) of a reference image, she stated that the quality of the WebP-encoded result was the worst of the three, mostly because of blurriness on the image. Her main remark was that "libvpx, a much more powerful encoder than ffmpeg's jpeg encoder, loses because it tries too hard to optimize for PSNR" (peak signal-to-noise ratio), arguing instead that "good psycho-visual optimizations are more important than anything else for compression".[25] In October 2013, Josh Aas from Mozilla Research published a comprehensive study of current lossy encoding techniques[109] and was not able to conclude that WebP outperformed JPEG by any significant margin.[110]

Additional criticism of WebP includes the fact that while ubiquitous on the Internet, there remains a significant lack of support for the file type, with Wes Fenlon of PC Gamer describing them as "rampant" and "annoying", commonly rejected for uploading by various content management systems and other software programs, with Photoshop not officially supporting them until February 2022. Noting that the WebP format was entirely pushed by Google to replace traditional image formats, he posited that Google was "salty" that the VP8 video standard it created did not catch on and began promoting WebP as a "twisted act of revenge", albeit without evidence. He singled out as a point of particular annoyance the fact that WebP images were often downloaded as JPEGs or PNGs despite not actually being that file format, due to the replacement of source image files with WebP ones by content delivery networks to slightly save on bandwidth, but making it difficult for people to use an image after they had downloaded it, something that overshadowed the bandwidth savings with major inconvenience to users. He described "every website that serves them to me while holding a JPEG hostage" as his "sworn enemy".[111]

Vulnerability

[edit]

In September 2023, two critical vulnerabilities[112] relating to WebP images were discovered by Apple Security Engineering and Architecture (SEAR) and the Citizen Lab, potentially affecting Google Chrome, Chromium-based browsers and the libwebp project from Google, among any application implementing libwebp.

Among these vulnerabilities, CVE-2023-4863 was an actively exploited vulnerability with a high risk rating of CVSS 8.8. This could lead to an out of bounds/overflow condition in applications using the affected libwebp library, upon exploitation of a maliciously crafted .webp lossless file. This could result in a denial of service (DoS), or worse, enabling malicious remote code execution (RCE).

The extensive use of libwebp packages across hundreds of applications, including many categories from web browsers to mobile apps, posed a major patching challenge to mitigate the vulnerability due to the demanding testing requirements before release, highlighting the implications of this vulnerability on a wide scale.

Several web browsers, including Google Chrome, Firefox, Microsoft Edge, and Brave issued security patches following the discovery of the vulnerability.[113] The vulnerability was patched in libwebp version 1.3.2.[114][115]

WebP 2

[edit]

Google began developing a second version of WebP in June 2021. The main goal of WebP 2 was to reach similar compression ratios as AVIF while remaining faster to encode and decode.[116] Its reference implementation is libwebp2.

On 12 October 2022, Google changed the README file in WebP 2's development repository to state "WebP 2 will not be released as an image format" and described WebP 2 as a "playground for image compression experiments".[117]

See also

[edit]
  • Comparison of graphics file formats
  • AVIF, an image format based on the AV1 video format[118]
  • BPG, an image format intended to be a more compression-efficient replacement for the JPEG image format, based on the intra-frame encoding of the High Efficiency Video Coding (HEVC) video compression standard, introduced in 2014.
  • FLIF, a discontinued lossless image format which claimed to outperform PNG, lossless WebP, lossless BPG and lossless JPEG2000 in terms of compression ratio, introduced in 2015. FLIF was superseded by JPEG XL.
  • HEIF, another image format based on HEVC, now also incorporating AVIF and VVC
  • HEIC, an image format based on HEVC, widely used by Apple devices.
  • From the Joint Photographic Experts Group:
    • JPEG LS, an old but efficient lossless format, introduced in 1999.
    • JPEG 2000, an improvement intended to replace the older JPEG by the JPEG committee, introduced in 2000.
    • JPEG XR, an alternative to JPEG 2000 supporting HDR and wide gamut color spaces, introduced in 2009.
    • JPEG XL, particularly optimised for responsive web environments, so that content renders well on a wide range of devices. Moreover, it includes several features that help transition from the legacy JPEG format. JPEG XL was introduced at the end of 2020.
  • MNG and APNG, PNG-based animated image formats, supporting lossless 24-bit RGB color and 8-bit alpha channel.

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

WebP

View on Grokipedia
from Grokipedia
WebP is a modern raster image file format developed by Google, utilizing both lossy and lossless compression algorithms derived from the VP8 video codec to enable smaller file sizes while maintaining high visual quality for web images. It supports transparency (alpha channel) in both compression modes and animated sequences, serving as an efficient alternative to established formats like JPEG for photographs, PNG for graphics with transparency, and GIF for simple animations. Introduced on September 30, 2010, as an open-source standard, WebP aims to accelerate web page loading by reducing image data, which accounts for a significant portion of web traffic. Key advantages of WebP include substantial reductions: lossy WebP images are typically 25–34% smaller than equivalent JPEGs at comparable levels, while lossless WebP files are about 26% smaller than PNGs. was added on November 18, 2011, enhancing its versatility for scenarios requiring exact image reproduction, such as diagrams or icons, and enabling alpha transparency that results in files up to three times smaller than PNG equivalents in lossy mode. Animated WebP, introduced later to support frame-by-frame sequences with optional lossy or lossless encoding and transparency, offers significantly reduced sizes compared to GIF and APNG, promoting faster rendering on devices. WebP has gained broad adoption, with native support in major browsers including (since version 17 for lossy), Mozilla Firefox, Apple Safari, , and , as well as in operating systems like Android and . The format's , libwebp, provides encoding and decoding tools (cwebp and dwebp) under a BSD license, facilitating integration into web servers, systems, and image editing software. Despite its benefits, WebP's rollout faced initial challenges due to limited early browser compatibility, but by 2025, it has become a standard recommendation for optimizing .

History

Development and Initial Release

Google developed WebP as an initiative to enhance by significantly reducing the size of image files, addressing the fact that images accounted for approximately 65% of bytes at the time. The format was publicly announced on , 2010, as a free and open-source format under a BSD license, leveraging technology from the video codec that Google had open-sourced in May 2010 as part of the multimedia project. The core motivations behind WebP included achieving superior compression efficiency over established formats like for lossy encoding and for lossless encoding, with planned extensions for alpha transparency and capabilities to serve as a modern alternative to . Initial development focused on adapting VP8's intra-frame video compression techniques to still images within a lightweight RIFF-based , aiming to enable faster page loads and lower bandwidth usage without sacrificing visual quality. Google released a developer preview alongside the announcement, featuring the libwebp reference library for encoding and decoding, along with command-line tools for converting existing images to WebP. Integration with the rendering engine was planned from the outset, with a patch developed for to enable native support in an upcoming release of , beginning with version 9 in early 2011. Early evaluations by highlighted WebP's potential impact, claiming an average 39% reduction in file size compared to across a dataset of over one million web images, while maintaining equivalent perceptual quality as measured by standard metrics. These benchmarks underscored WebP's role in 's broader push for an open web media ecosystem.

Subsequent Updates and Milestones

Lossless compression for WebP was announced on November 18, 2011, with initial integration into Google Chrome 17. This update built on the format's foundational lossy compression by adding support for lossless modes, enabling smaller file sizes for graphics without quality degradation in scenarios requiring exact reproduction. The Chrome integration marked a key step toward practical deployment, allowing developers to test WebP on live web pages without plugins. libwebp version 0.2.0, released in August 2012, enabled lossless support by default. In 2012, adoption accelerated with adding native WebP support in version 12.1, expanding compatibility beyond Chrome and encouraging broader experimentation. In October 2011, Google released the first public samples of animated WebP files, demonstrating the format's potential for replacing GIFs with more efficient, high-quality animations featuring 24-bit . A major milestone arrived in 2018 with the stable release of libwebp 1.0 on April 21, which optimized encoding speeds by up to 30% for lossy modes and improved overall quality metrics through refined chroma handling and reduced artifacts. These enhancements made WebP more viable for high-volume encoding workflows, such as content delivery networks, without compromising on compression efficiency. Between 2020 and 2023, WebP gained deeper integration across mobile ecosystems, including native support in (API level 30), which streamlined decoding and encoding for apps and system-level image handling. This period also saw expanded use in systems and libraries, driving practical adoption in mobile-first development. By 2024 and into 2025, WebP became the default format in key services like Search and . The announcement of WebP 2 development in June 2021 served as a forward-looking , aiming to achieve compression parity with emerging formats like while maintaining . An important enabler for widespread adoption was the resolution of patent concerns in , when reached a licensing agreement with and 11 patent holders covering techniques essential to WebP, confirming its royalty-free status and alleviating legal uncertainties.

Technology

Core Features and Container Format

WebP is a raster graphics format developed by that employs the (RIFF) as its container structure, with the file beginning with a 'WEBP' chunk to denote the format. This chunk-based RIFF design allows for modular organization of data, enabling the inclusion of various components such as image streams, metadata, and extensions within a single file up to approximately 4 GiB in size. The format's flexibility supports both still images and animations, making it suitable for web delivery. A key strength of WebP lies in its unified support for both lossy and lossless compression modes, alongside an 8-bit alpha channel that facilitates transparency in RGBA color spaces with 24-bit RGB depth. Lossy images use the VP8 chunk for data storage, while lossless ones utilize the VP8L chunk; the VP8X chunk signals extended capabilities like alpha blending or animation when present. This integration allows WebP to handle photographic content efficiently in lossy mode and graphics with sharp edges or transparency in lossless mode, all within the same container. WebP accommodates embedded metadata through dedicated chunks, including for exchangeable image file format data, for descriptions, and ICC profiles for , all nested under the VP8X extension for enhanced interoperability. The standard file extension is .webp, and the registered type is image/webp, ensuring broad recognition across web platforms and applications. At its core, the WebP encoding pipeline begins by partitioning the input image into 16x16 macroblocks, which are subsequently refined through intra-prediction to exploit spatial redundancies and to compress the residual data efficiently. This high-level process underpins the format's performance, yielding typical file size reductions of 25-34% over equivalent-quality images in lossy mode and approximately 26% over in lossless mode. When transparency is involved, lossy WebP with lossless alpha can achieve 60-70% smaller sizes than transparent files.

Lossy Compression

WebP's mechanism derives from the intra-frame encoding of the video codec, where static s are processed as individual key frames in a video , utilizing block-based to exploit spatial redundancies within the . The encoding begins by partitioning the into 16×16 macroblocks, which are subdivided into smaller units: 4×4 blocks for (brightness) details, 16×16 blocks for broader luma , and 8×8 blocks for chroma (color) components. This approach allows for targeted compression of and separately, enhancing overall efficiency. Spatial prediction forms a core technique, employing ten distinct modes per 4×4 luma block to estimate values from already decoded neighboring pixels. These modes reduce the residual that needs to be encoded by capturing local correlations effectively. The residuals undergo a (DCT) on 4×4 blocks, which converts spatial into frequency-domain coefficients, concentrating most energy in low-frequency components and producing many zeros for subsequent compression. This is followed by arithmetic , which adaptively assigns shorter codes to frequent symbols, outperforming traditional in efficiency. Quantization introduces the irreversible loss, scaling the DCT coefficients by a quantization parameter (QP) to discard less perceptible high-frequency details, controlled via an adjustable quality factor from 0 (maximum compression, lowest quality) to 100 (minimal loss, highest quality). To further optimize color encoding, WebP uses YUV 4:2:0 chroma subsampling, halving the horizontal and vertical resolution of chroma channels relative to luma, as human vision is less sensitive to color variations than brightness. Compared to JPEG, WebP's lossy mode delivers superior quality at equivalent low bitrates, thanks to advanced spatial prediction that better captures edges and textures, combined with in-loop deblocking and deringing filters that mitigate artifacts like blocking. These enhancements, along with adaptive per-block quantization, enable 25–34% smaller file sizes at matched perceptual quality metrics such as SSIM. Encoding remains computationally intensive, typically 10–20 times slower than JPEG due to the complex prediction and transform processes, but decoding is faster, benefiting web rendering.

Lossless Compression

WebP's lossless compression mode, denoted as VP8L, enables the exact reproduction of original data without any quality loss, making it a suitable replacement for formats like . This mode employs an entropy-coded spatial prediction scheme that exploits correlations between neighboring pixels to reduce redundancy. Specifically, it uses 14 different predictors applied in scan-line order, where each pixel's value is estimated based on its left (L), top (T), top-left (TL), and top-right (TR) neighbors, with the residual encoded to minimize bits. Additionally, backward references inspired by LZ77 allow referencing previous segments, using distance and length codes that prioritize short distances within a 120-pixel neighborhood for efficiency. A color cache further optimizes storage by indexing up to 2^11 recently used colors via a , reducing the encoding of repeated color values. The compression process begins with a series of reversible transforms to decorrelate the image data. The subtract-green transform removes the green channel's influence from red and blue channels by subtracting green values, which is particularly effective for natural images where green dominates. For images with limited colors, a palette transform indexes pixels to a table of up to 256 entries, bundling multiple pixels per code when the palette size is small (≤16 colors). The predictor transform divides the image into blocks and selects one of the 14 predictors per block using the green channel value as an index. A color transform then applies a reversible decorrelation similar to the YCoCg-R space, preserving the green channel while adjusting red and blue based on predefined deltas (e.g., red transformed as R - ((B + G) >> 1), with inverse operations ensuring bit-exact reversibility). Following these transforms, entropy coding uses spatially variant Huffman tables—up to five per pixel group for green, red, blue, alpha, and distances—with prefix codes that adapt to local statistics, typically achieving 14-19 bits per pixel depending on image complexity. WebP supports lossless transparency through direct encoding of the alpha channel as a separate plane, integrated into the ARGB without any or lossy approximations, ensuring precise preservation of semi-transparent regions. This approach contrasts with formats that might compress alpha indirectly, allowing VP8L to maintain full for images with varying opacity. In terms of efficiency, VP8L achieves compressed file sizes approximately 26% smaller than equivalent PNGs on average, as demonstrated across diverse web image corpora, owing to the combined effects of spatial , backward references, and color caching that better exploit image redundancies than PNG's DEFLATE-based method. The can be quantified as Compression ratio=original size−compressed sizeoriginal size,\text{Compression ratio} = \frac{\text{original size} - \text{compressed size}}{\text{original size}}, where VP8L typically yields ratios 22-30% higher than optimized PNG variants through these integrated techniques, with studies showing 23% improvement over size-optimized PNGs like ZopfliPNG for translucent images. While VP8L encoding is generally slower than PNG due to the iterative optimization of transforms and Huffman tables for maximum density, decoding performance is comparable or faster, averaging around 0.003 seconds per image versus 0.005 seconds for PNG on typical web content, facilitating efficient rendering in resource-constrained environments.

Animation Support

Animated WebP extends the format's capabilities to support animated images through the (RIFF) container, utilizing specific chunks to define frame sequences and playback parameters. The core structure includes an 'ANIM' chunk for global animation settings, such as loop count and background color, followed by multiple 'ANMF' chunks, each representing an individual frame in display order. Each 'ANMF' chunk encapsulates frame metadata, including position (X and Y offsets, 24-bit values scaled by 2), dimensions (width and height minus one, 24-bit), and duration in milliseconds (24-bit value). This allows for sequences of full or partial , enabling efficient incremental updates through , where subsequent reference and modify only changed regions rather than the entire . Frames in animated WebP can employ via the codec, via VP8L, or a mixed approach combining VP8 with an 'ALPH' chunk for transparency. Delta frames leverage inter-frame , particularly in lossy mode, to reduce redundancy by encoding differences from previous frames, similar to video codecs. This , along with support for partial frame updates, contributes to significant efficiency gains: animated WebP files are typically 64% smaller than equivalent GIFs when using , based on conversions of a corpus of approximately 7,000 GIFs. Playback control mirrors aspects of GIF, with looping defined by the 'ANIM' chunk's 16-bit loop count (0 for infinite repetition) and a specified background color applied during disposal. Disposal methods are limited to two options per frame: none (retaining the frame as is for the next) or dispose to background (clearing the frame rectangle to the background color). Blending modes further refine rendering: alpha-blending (0) composites the frame over the previous one using transparency, while replace (1) discards the prior frame content before drawing the new one. Frame durations are precisely controlled in milliseconds, allowing smooth animations with fine-grained timing. The libwebp library provides tools for encoding animated WebP, notably img2webp, which converts sequences of input images (e.g., or ) into animated files. It supports flags such as -loop <count> to set the number of repetitions (default infinite) and -d <ms> to specify per-frame delay (default 100 ms), alongside options for lossless/lossy modes and keyframe intervals to optimize compression and seeking.

Comparisons with Other Formats

Versus JPEG and PNG

WebP's lossy compression offers significant advantages over for photographic images, achieving file sizes that are 25-34% smaller while maintaining equivalent visual quality as measured by the Structural Similarity Index (SSIM). This efficiency stems from WebP's use of VP8-based encoding, which employs and adaptive quantization to distribute bits more evenly across the image, reducing visible artifacts compared to 's discrete cosine transform (DCT) method. In particular, WebP minimizes blocky artifacts around edges and high-contrast areas that are common in at similar compression levels, providing sharper details without the characteristic 8x8 pixel blocking. benchmarks from 2010 onward demonstrate that WebP encoded at 80% quality often matches or exceeds the perceptual quality of at 90% quality across diverse datasets like Kodak and Tecnick, with SSIM scores typically above 0.95 for both but WebP requiring fewer bits per pixel. For lossless compression, WebP provides a compelling alternative to , particularly for , , and images requiring transparency, with file sizes approximately 26% smaller on average. Evaluations confirm WebP outperforms standard PNG libraries by 42% and optimized variants like ZopfliPNG by 23% in terms of compression density, while preserving perfect fidelity (SSIM of 1.0). Unlike , where transparency via alpha channels is optional and can increase file sizes substantially for opaque images, WebP integrates alpha support natively in its for both lossy and lossless modes, enabling efficient handling of semi-transparent elements without additional overhead. This makes WebP preferable for web where PNG's palette-based optimization excels for simple colors but falls short in spatial prediction for complex scenes. In practical use cases, WebP lossy is favored over for web photographs due to faster loading times and reduced bandwidth, especially on mobile devices, while its lossless mode suits PNG's domain of icons and diagrams by combining smaller sizes with built-in transparency. Additionally, WebP's royalty-free status under a BSD license addresses historical licensing concerns associated with 's , promoting broader adoption without legal barriers.

Versus GIF and AVIF

WebP animations provide significant advantages over , primarily through superior and compression efficiency. Unlike , which is limited to an 8-bit palette supporting only 256 colors, WebP animations utilize 24-bit RGB , enabling millions of colors without the need for dithering artifacts that often degrade quality in complex visuals. This full-color support makes WebP ideal for vibrant, detailed animations where 's palette restrictions lead to banding or posterization. Additionally, Google's benchmarks on a corpus of approximately 7,000 animated s demonstrate that lossy WebP conversions achieve a 64% reduction compared to the originals, resulting in files roughly three times smaller on average, while lossless WebP yields a 19% reduction. These efficiencies stem from WebP's advanced compression algorithms, allowing for high-quality animations with reduced bandwidth demands suitable for web delivery. In comparison to , a newer format based on the video codec, WebP offers a balance of performance and compatibility, though AVIF excels in certain areas. An experimental codec known as WebP 2, under development, aims for compression efficiencies similar to AVIF with about 30% better than WebP 1.x and support for 10-bit HDR. However, current implementations of WebP (version 1.x) provide faster encoding and decoding speeds, making it more practical for applications where AVIF's AV1 foundation results in slower processing—often 2-4 times longer decode times. AVIF demonstrates superior , producing files 20-30% smaller than equivalent WebP images at matched quality levels, particularly for photographic content, and it outperforms in HDR scenarios with up to 12-bit versus WebP's standard 8-bit. For animations, AVIF's support remains incomplete in 2025, with browser implementations like requiring experimental flags and offering only partial sequence handling, limiting its reliability compared to WebP's mature animation framework. Key trade-offs highlight WebP's established maturity against AVIF's open, AV1 foundation, which promotes broader long-term adoption without licensing concerns—though both formats are royalty-free overall. WebP's longer development history ensures better legacy compatibility across older devices and software, reducing fallback needs in mixed environments. As of November 2025, WebP sees higher usage with approximately 18.1% of websites implementing it, including many top sites, compared to AVIF's 1.0% overall penetration, reflecting WebP's edge in practical deployment despite AVIF's growing browser support at around 93%.

Support and Adoption

Web Browser Support

WebP has achieved widespread native support across major web browsers by 2025, enabling efficient rendering of its lossy, lossless, animated, and transparent variants without requiring plugins. Google Chrome introduced initial support for basic lossy WebP images in version 17, released in October 2011. Full support, including lossless compression, alpha transparency, and animation, arrived in Chrome 32 in January 2014. With Chrome holding approximately 66% of the global browser market share as of Q3 2025, nearly 99% of Chrome users benefit from complete WebP compatibility. Mozilla added full WebP support in version 65, released in January 2019, covering all features including animation and transparency; prior versions offered no support. As commands about 3.8% of the market as of Q3 2025, this equates to roughly 95% coverage among its user base. Apple implemented WebP support starting with version 14 in September 2020, requiring (11) or later for desktop and for mobile devices. By 2025, with iOS adoption exceeding 90% on compatible devices, users largely experience full feature support. Microsoft Edge gained full WebP support in version 18, released in 2018, following its transition to the engine; the legacy never supported WebP. provided partial support from version 11.5 in 2011, with full compatibility—including animation—arriving in version 19 in 2013. As of 2025, WebP enjoys approximately 97% global browser support, leaving less than 1% of users—primarily on outdated versions—without native decoding. Developers commonly employ fallback strategies, such as the HTML <picture> element to serve alternative formats like or , or polyfills for legacy browsers.
BrowserInitial SupportFull Support (incl. Animation/Transparency)Notes
Chromev17 (2011, lossy only)v32 (2014)Dominant ensures broad coverage.
None before v65v65 (2019)Comprehensive from launch.
None before v14v14 (2020, OS-dependent)Requires macOS 11+ or +.
EdgeNone before v18v18 (2018)IE11 unsupported.
v11.5 (2011, partial)v19 (2013)Aligns with timeline.

Graphics Software Support

Various graphics software applications have integrated support for creating, editing, and converting WebP files, often leveraging the open-source libwebp library developed by for encoding and decoding capabilities. This library underpins WebP functionality in many tools, enabling both and as well as handling where supported. Command-line utilities like cwebp, part of the libwebp suite, are commonly used for batch conversions and scripting in professional workflows. Adobe Photoshop provides WebP support through the WebPShop plugin, which has been available since 2011 for opening, editing, and saving WebP images, including animations. Native integration was added in Photoshop version 23.2, released in 2022, allowing direct import and export without plugins, though some advanced features like encoding previews remain plugin-dependent. Import operations in Photoshop rely on libwebp for decoding. The image editor has offered native WebP support since version 2.10, released in May 2018, including full encoding and decoding for both static and animated files, along with and metadata preservation. supports WebP via a dedicated plugin developed around 2015, which enables loading and saving of WebP images. This plugin became bundled natively starting with version 4.2.5, released on October 1, 2019, providing seamless integration for users. IrfanView and , popular for image viewing and , have provided full WebP read/write support since version 4.40 (2012) via plugins, facilitating efficient conversion of large image sets. Both tools excel in batch operations, allowing users to convert formats like or to WebP while preserving quality settings. Affinity Photo introduced WebP export support in version 2.0 (November 2022), with subsequent updates enhancing compatibility for professional editing tasks. By 2024, version 2.4 further improved export options, including better handling of lossless modes for web-optimized workflows.

Other Applications and Libraries

WebP has been integrated into various operating systems for native or extended viewing capabilities. On and later versions, WebP images can be viewed using the built-in Photos app and thumbnails following the installation of the official WebP Image Extension, which has been available since 2018 and provides support for lossy, lossless, and animated formats. For macOS, WebP support is available through WebKit-based applications since Safari 14, released in 2020, enabling decoding in compatible environments. On Linux distributions, WebP is supported via tools like , which includes encoding and decoding options for the format in its core functionality. In mobile operating systems, WebP decoding has been natively available on Android since version 4.0 ( level 14, released in 2011), supporting , with lossless and transparency features added in Android 4.3 ( level 18). Encoding capabilities for WebP are facilitated through Android's .compress method since level 14 for lossy images and level 17 for lossless, though advanced features like animated WebP decoding were expanded in Android 9 and later. On , WebP support is provided via since (2020), allowing decoding in and other WebKit-dependent apps. Developer libraries play a key role in WebP integration beyond core OS features. Google's libwebp, a C-based reference for encoding and decoding WebP images, reached version 1.6.0 in June 2025, incorporating improvements such as optimized x86 instructions (AVX2 and ) for faster processing. Wrappers like Sharp for provide high- WebP encoding and decoding, supporting conversions from formats like , , and while handling lossless, lossy, and animated variants. Similarly, Python's supports WebP operations, including opening, saving, and converting images, provided the underlying libwebp is installed on the system. Several applications leverage WebP for efficient image handling. has supported uploading, displaying, and using WebP images since version 5.8 (released in July 2021), treating them equivalently to and files in media libraries and themes. Messaging platforms like Telegram utilize WebP exclusively for static stickers, requiring images to be in WebP format with specific dimensions (e.g., 512 pixels on one axis) and transparency support. added support for animated WebP images in March 2025, enhancing media uploads and displays across its infrastructure for reduced file sizes compared to . Server-side and content management adoption of WebP continues to grow through tools like version 7.1 and later, which offer robust WebP encoding options including quality settings, lossless modes, and animation handling for in web environments.

Criticisms and Limitations

Compatibility Challenges

One significant compatibility challenge for WebP arises from its lack of support in legacy web browsers. does not support WebP, and versions of prior to 14.0 also lack native decoding capabilities, requiring macOS 11 or later for implementation in Safari 14 through 15.6. Although these browsers account for less than 1% of global usage in 2025, they remain prevalent in enterprise environments where updating systems is often restricted by security policies or legacy software dependencies. In email applications, WebP adoption is uneven, complicating its use in communications. Outlook's desktop client does not provide native support for WebP images, necessitating fallbacks to formats like or to ensure display. has supported WebP since 2011, but it often automatically converts WebP files to for broader compatibility, potentially losing lossless details or transparency. Hardware-level support for WebP decoding is limited, particularly on older graphics processing units (GPUs) and peripheral devices. WebP relies primarily on software decoding in most implementations, which can increase latency on devices with limited CPU resources. Similarly, many printers and scanners ignore WebP files due to their focus on established formats like and TIFF, requiring manual conversion before use in printing or scanning workflows. Beyond web browsers, email, and hardware, WebP encounters compatibility issues in various desktop applications and software tools. The Windows Photos app does not natively support opening .webp files, often failing to display them without additional codecs or requiring conversion to formats like JPEG or PNG using third-party utilities. Microsoft Paint can display WebP files via installed codecs but may necessitate conversion for full editing capabilities. In video editing software, such as DaVinci Resolve, support for WebP images is limited or inconsistent, with reported issues like importing images as single frames or complete lack of support in earlier versions, compelling users to convert files to PNG or JPEG for seamless workflows. To address these gaps, developers often employ conversion tools and strategies that add overhead. Google's official cwebp command-line tool and libraries like libwebp enable batch conversion of WebP to compatible formats for non-supporting platforms, while online services such as CloudConvert provide quick transformations without installation. A common web practice is double-serving images—delivering WebP to supporting clients via the <picture> element and fallbacks to or otherwise—which ensures compatibility but doubles storage and bandwidth demands on servers. Criticisms of WebP's rollout highlight how Google's promotion through tools like PageSpeed Insights has accelerated browser adoption but contributed to a perception of fragmented web standards. Early resistance from software vendors, including delayed support in until , slowed ecosystem integration, forcing developers to maintain multiple format pipelines and exacerbating interoperability issues in diverse environments.

Performance and Quality Issues

In lossy mode, WebP images at quality settings below 50 often display prominent ringing and blocking artifacts, manifesting as halo-like distortions around edges and grid-like patterns in uniform areas. These issues are exacerbated in smooth gradients, where WebP performs worse than JPEG, producing posterization effects such as unintended magenta or green rings in scanned film or portraits. WebP encoding is significantly slower than that of JPEG or PNG, typically 5-10 times longer for lossy compression due to its advanced prediction and transformation techniques, making it resource-intensive for batch processing or real-time applications. While decoding is relatively efficient—about 1.5 times slower than JPEG—it remains CPU-demanding, particularly on mobile devices with limited processing power. Objective quality metrics reveal WebP's limitations compared to newer formats; for instance, achieves higher PSNR and SSIM scores at equivalent bitrates, indicating better preservation of structural details and reduced distortion. As of 2025, WebP remains limited to depth per channel without native support for (HDR), leading to color banding in images with subtle gradients or high dynamic range, unlike which supports up to 12-bit and HDR. Real-world bandwidth savings with WebP are more modest than initially claimed, averaging 15-25% file size reduction over in practical web scenarios, depending on image content like photographs versus graphics, rather than the advertised 30% or more. Critics argue that has overhyped WebP's advantages, with its quality gains often marginal and artifacts making preferable for crisp, line-art graphics where lossless fidelity without banding is essential.

Security Vulnerabilities

Known Issues and CVEs

One of the most critical vulnerabilities in libwebp, the for WebP, is CVE-2023-4863, a heap buffer overflow in the lossless decoder (VP8L) that enables out-of-bounds memory writes. This flaw, with a CVSS score of 8.8, stems from inadequate validation during Huffman code table allocation and access, allowing attackers to craft malformed WebP files that overflow allocated heap buffers. It affects libwebp versions prior to 1.3.2 and was actively exploited in the wild, impacting applications like before version 116.0.5845.187. Earlier vulnerabilities include multiple integer overflows in libwebp, such as those documented in CVE-2016-9085, which allow unspecified impacts through crafted inputs during decoding. These flaws arise from improper handling of integer values in decoding routines, leading to buffer overflows similar to later issues. In 2025, Google Project Zero detailed an exploit chain (BLASTPASS) that leveraged a WebP vulnerability in for zero-click attacks via , highlighting ongoing risks in image parsing. Common root causes across these vulnerabilities involve integer overflows during chunk parsing in WebP files, such as in ParseOptionalChunks, where unvalidated sizes lead to incorrect memory allocations and subsequent remote code execution potential. For instance, oversized frame or chunk dimensions in animated WebP files can cause stride calculation overflows, enabling heap corruption. These issues broadly affect decoders in web browsers like Chrome and Electron-based applications, as well as other software embedding libwebp.

Exploitation Cases and Mitigations

In 2023, a zero-day vulnerability designated CVE-2023-4863 was actively exploited in Google Chrome versions prior to 116.0.5845.187, enabling remote attackers to perform out-of-bounds memory writes via specially crafted WebP images processed by the libwebp library. This flaw was patched in Chrome 116.0.5845.187 on September 12, 2023, following reports of in-the-wild exploitation. A notable exploitation case involved NSO Group's Pegasus spyware in the BLASTPASS attack chain, which targeted iOS devices via iMessage attachments containing malicious WebP images in lossless format. Delivered as PKPass files, these exploits leveraged the WebP vulnerability within Apple's ImageIO framework to achieve zero-click remote code execution, bypassing the BlastDoor sandbox and enabling surveillance on iOS versions up to 16.6. The attack was captured in the wild in 2023, with detailed analysis released by Google Project Zero in March 2025 confirming the role of Huffman table overflows in the VP8L chunk. Additional exploitation vectors emerged in Electron-based applications, where the vulnerability allowed remote code execution through HTML tags rendering untrusted WebP content, affecting apps like and prior to library updates. On Android, the flaw impacted image-processing applications, including gallery apps that decode WebP files, potentially leading to heap overflows when handling malicious media from unverified sources in 2023. To mitigate these risks, released libwebp version 1.3.2 on September 13, 2023, addressing the core in the WebP codec. Browser vendors enhanced protections through (ASLR) and continuous fuzzing of image decoders, while site isolation and renderer sandboxes in Chromium-based browsers confined potential remote code execution to isolated processes, reducing system-wide impact. Security recommendations emphasize server-side validation of WebP images to detect malformed files before delivery, alongside mandatory updates to libwebp 1.3.2 or later in all dependent applications. Web developers are advised to sanitize untrusted uploads and avoid direct rendering of external WebP content without verification, as highlighted in post-incident guidance from 2023. In response, the Chromium project intensified fuzzing efforts on libwebp and related codecs to proactively identify similar flaws, contributing to broader ecosystem hardening against image-based attacks.

WebP 2

Development and Goals

Google announced the development of WebP 2 in late 2020 as a successor to the original WebP format, aiming to enhance its capabilities in response to evolving image compression standards. This initiative was driven by the need to address limitations in WebP 1.0, particularly its slower encoding speeds compared to decoding, and to position it competitively against newer formats like AVIF, which leverages the AV1 video codec for superior efficiency. The project maintains WebP's royalty-free status under the BSD license, ensuring broad accessibility for web developers and applications. The primary goals of WebP 2 include achieving 20-30% better compression efficiency over WebP 1.0 for lossy images, while preserving or improving support for , transparency, , and incremental decoding. It also introduces support for (HDR) imaging via a 10-bit architecture compatible with , enabling richer visuals on modern displays. These enhancements target reduced file sizes for web and mobile use cases, ultimately improving load times and user experience without sacrificing quality. As of 2025, WebP 2 remains in an experimental prototype phase, with the libwebp2 library serving as its integrated into 's for testing. No full public release as a standard format has occurred, though alpha-level tools and binaries are available through the project's repository for developers to experiment with compression techniques. The development, led by engineers focused on performance optimization, emphasizes to ensure existing WebP 1.0 files can be processed seamlessly.

Planned Features and Status

WebP 2 is an experimental image codec developed by , building on the original WebP format to explore advancements in compression and related capabilities. It focuses primarily on enhancing lossy and , achieving approximately 30% better in lossy modes compared to WebP 1.0, as demonstrated in internal benchmarks. Key experimental features include support for 10-bit HDR encoding, improved methods, animation handling with incremental decoding, and full multi-threading for both encoding and decoding processes to optimize on modern hardware. These enhancements aim to better handle web-typical content such as photographs, graphics with transparency, and short animations, while maintaining compatibility with existing WebP tools where possible. As of November 2025, the project remains active in 's repository with ongoing maintenance activity. However, has explicitly stated that WebP 2 will not be released as a production image format; instead, it serves as a to test ideas that could inform future iterations of libwebp or other compression technologies. No public beta, browser trials, or efforts, such as through the W3C, are planned.

References

  1. https://developers.google.com/speed/webp
  2. https://developers.google.com/speed/webp/docs/riff_container
  3. https://developers.googleblog.com/en/webp-a-new-image-format-for-the-web/
  4. https://developers.googleblog.com/en/lossless-and-transparency-encoding-in-webp/
  5. https://developers.google.com/speed/webp/faq
  6. https://developers.google.com/speed/webp/docs/using
  7. https://blog.chromium.org/2010/05/webm-and-vp8-land-in-chromium.html
  8. https://www.keycdn.com/support/webp-support
  9. https://white64.com/articles/the-rise-of-webp/
  10. https://developer.android.com/studio/write/convert-webp
  11. https://www.zdnet.com/article/google-and-mpeg-la-settle-long-running-vp8h-264-patent-dispute/
  12. https://datatracker.ietf.org/doc/rfc9649/
  13. https://developers.google.com/speed/webp/docs/compression
  14. https://developers.google.com/speed/webp/docs/webp_study
  15. https://blog.webmproject.org/2010/07/inside-webm-technology-vp8-intra-and.html
  16. https://developers.google.com/speed/webp/docs/webp_lossless_bitstream_specification
  17. https://developers.google.com/speed/webp/docs/webp_lossless_alpha_study
  18. https://www.rfc-editor.org/rfc/rfc9649.html
  19. https://chromium.googlesource.com/webm/libwebp/+/HEAD/doc/tools.md
  20. https://chromium.googlesource.com/codecs/libwebp2/
  21. https://speedvitals.com/blog/webp-vs-avif/
  22. https://shortpixel.com/blog/avif-vs-webp/
  23. https://caniuse.com/avif
  24. https://w3techs.com/technologies/details/im-webp
  25. https://w3techs.com/technologies/details/im-avif
  26. https://caniuse.com/webp
  27. https://www.keycdn.com/support/webp-browser-support
  28. https://webptopng.dev/webp-browser-support/
  29. https://developers.google.com/speed/webp/download
  30. https://github.com/webmproject/WebPShop
  31. https://helpx.adobe.com/photoshop/kb/support-webp-image-format.html
  32. https://www.gimp.org/release-notes/gimp-2.10.html
  33. https://forums.getpaint.net/topic/21773-webp-filetype-2025-09-20/
  34. https://blog.getpaint.net/2019/10/01/paint-net-4-2-5-is-now-available/
  35. https://www.irfanview.com/plugins.htm
  36. https://newsgroup.xnview.com/viewtopic.php?t=41474
  37. https://forum.affinity.serif.com/index.php?/topic/172002-affinity-photo-2-support-of-webp-format/
  38. https://www.cgchannel.com/2024/02/serif-releases-affinity-photo-2-4/
  39. https://apps.microsoft.com/detail/9pg2dk419drg
  40. https://developer.apple.com/documentation/safari-release-notes/safari-14-release-notes
  41. https://imagemagick.org/script/webp.php
  42. https://github.com/lovell/sharp
  43. https://make.wordpress.org/core/2021/06/07/wordpress-5-8-adds-webp-support/
  44. https://core.telegram.org/stickers
  45. https://discord.com/blog/modern-image-formats-at-discord-supporting-webp-and-avif
  46. https://www.caniemail.com/features/image-webp/
  47. https://github.com/WordPress/performance/issues/74
  48. https://groups.google.com/a/webmproject.org/g/webp-discuss/c/e1ZzTJOfIyg
  49. https://blog.chromium.org/2011/05/webp-in-chrome-picasa-gmail-with-slew.html
  50. https://learn.microsoft.com/en-us/answers/questions/4156426/windows-photos-app-support-for-webp-files
  51. https://learn.microsoft.com/en-us/answers/questions/5535954/why-i-cant-convert-convert-jpg-to-webp-with-the-ph
  52. https://learn.microsoft.com/en-us/answers/questions/3987751/new-windows-11-pc-how-to-save-web-images-as-jpeg
  53. https://www.reddit.com/r/davinciresolve/comments/182u6i6/is_the_lack_of_webp_support_a_conscious_decision/
  54. https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=225624
  55. https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=227129
  56. https://cloudconvert.com/webp-converter
  57. https://web.dev/articles/codelab-serve-images-webp
  58. https://webmasters.stackexchange.com/questions/129168/why-does-google-in-its-page-insights-tool-advise-to-use-webp-images-which-don
  59. https://www.reddit.com/r/webdev/comments/1fvy4oz/webp_is_actually_crazy_why_is_widespread_adoption/
  60. https://eng.aurelienpierre.com/2021/10/webp-is-so-great-except-its-not/
  61. https://chipsandcheese.com/p/modern-data-compression-in-2021-part-2-the-battle-to-dethrone-jpeg-with-jpeg-xl-avif-and-webp
  62. https://labs.clio.com/webp-a-personal-experiment-1570024459c4
  63. https://groups.google.com/a/webmproject.org/g/webp-discuss/c/hn3LwO6_bS0
  64. https://unifiedimagetools.com/en/articles/avif-webp-jpegxl-comparison-2025
  65. https://netflixtechblog.com/avif-for-next-generation-image-coding-b1d75675fe4
  66. https://www.researchgate.net/publication/376169205_Web_Image_Formats_Assessment_of_Their_Real-World-Usage_and_Performance_Across_Popular_Web_Browsers
  67. https://nvd.nist.gov/vuln/detail/CVE-2023-4863
  68. https://blog.cloudflare.com/uncovering-the-hidden-webp-vulnerability-cve-2023-4863/
  69. https://www.wiz.io/blog/cve-2023-4863-and-cve-2023-5217-exploited-in-the-wild
  70. https://www.cvedetails.com/cve/CVE-2016-9085/
  71. https://googleprojectzero.blogspot.com/2025/03/blasting-past-webp.html
  72. https://issues.chromium.org/40076489
  73. https://www.veracode.com/blog/resolving-webp-zero-day-vulnerability-cve-2023-4863/
  74. https://security.snyk.io/vuln/SNYK-JS-ELECTRON-5892810
  75. https://zimperium.com/blog/patching-high-impact-vulnerabilities-a-retrospective-on-webp-cve
  76. https://www.sophos.com/en-us/security-advisories/sophos-sa-20231002-libwebp-vuln
  77. https://www.chromium.org/Home/chromium-security/site-isolation/
  78. https://electronjs.org/blog/breach-to-barrier
  79. https://threatresearch.ext.hp.com/picture-this-exploit-exploring-the-webp-image-vulnerability-cve-2023-4863/
  80. https://www.phoronix.com/news/Google-Experimental-WebP2
  81. https://chromium.googlesource.com/codecs/libwebp2/+/refs/heads/main/README.md
  82. https://openbenchmarking.org/test/pts/webp2
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.