Frequently Asked Questions | WebP | Google for Developers (2024)

What is WebP? Why should I use it?

WebP is a method of lossy and lossless compression that can be used on a largevariety of photographic, translucent and graphical images found on the web.The degree of lossy compression is adjustable so a user can choose thetrade-off between file size and image quality. WebP typically achieves anaverage of 30% more compression than JPEG and JPEG 2000, without loss of imagequality (see Comparative Study).

The WebP format essentially aims at creating smaller, better looking imagesthat can help make the web faster.

Which web browsers natively support WebP?

Webmasters interested in improving site performance can easily createoptimized WebP alternatives for their current images, and serve them on atargeted basis to browsers that support WebP.

WebP lossy support
- Google Chrome (desktop) 17+
- Google Chrome for Android version 25+
- Microsoft Edge 18+
- Firefox 65+
- Opera 11.10+
- Native web browser, Android 4.0+ (ICS)
- Safari 14+ (iOS 14+, macOS Big Sur+)
WebP lossy, lossless & alpha support
- Google Chrome (desktop) 23+
- Google Chrome for Android version 25+
- Microsoft Edge 18+
- Firefox 65+
- Opera 12.10+
- Native web browser, Android 4.2+ (JB-MR1)
- Pale Moon 26+
- Safari 14+ (iOS 14+, macOS Big Sur+)
WebP Animation support
- Google Chrome (desktop and Android) 32+
- Microsoft Edge 18+
- Firefox 65+
- Opera 19+
- Safari 14+ (iOS 14+, macOS Big Sur+)

How can I detect browser support for WebP?

You'll want to serve WebP images only to clients that can display themproperly, and fall back to legacy formats for clients that can't. Fortunatelythere are several techniques for detecting WebP support, both on theclient-side and server-side. Some CDN providers offer WebP support detectionas part of their service.

Server-side content negotiation via Accept headers

It is common for web clients to send an "Accept" request header, indicatingwhich content formats they are willing to accept in response. If abrowser indicates in advance that it will "accept" the image/webp format,the web server knows it can safely send WebP images, greatly simplifyingcontent negotiation. See the following links for more information.

Modernizr

Modernizr is a JavaScript library for conveniently detecting HTML5 andCSS3 feature support in web browsers. Look for the propertiesModernizr.webp, Modernizr.webp.lossless, Modernizr.webp.alpha andModernizr.webp.animation.

HTML5 `<picture>` element

HTML5 supports a <picture> element, which allows you to list multiple,alternative image targets in priority order, such that a client will requestthe first candidate image that it can display properly. Seethis discussion on HTML5 Rocks. The <picture> element issupported by more browsers all the time.

In your own JavaScript

Another detection method is to attempt to decode a very small WebP image thatuses a particular feature, and check for success. Example:

// check_webp_feature:// 'feature' can be one of 'lossy', 'lossless', 'alpha' or 'animation'.// 'callback(feature, result)' will be passed back the detection result (in an asynchronous way!)function check_webp_feature(feature, callback) { var kTestImages = { lossy: "UklGRiIAAABXRUJQVlA4IBYAAAAwAQCdASoBAAEADsD+JaQAA3AAAAAA", lossless: "UklGRhoAAABXRUJQVlA4TA0AAAAvAAAAEAcQERGIiP4HAA==", alpha: "UklGRkoAAABXRUJQVlA4WAoAAAAQAAAAAAAAAAAAQUxQSAwAAAARBxAR/Q9ERP8DAABWUDggGAAAABQBAJ0BKgEAAQAAAP4AAA3AAP7mtQAAAA==", animation: "UklGRlIAAABXRUJQVlA4WAoAAAASAAAAAAAAAAAAQU5JTQYAAAD/////AABBTk1GJgAAAAAAAAAAAAAAAAAAAGQAAABWUDhMDQAAAC8AAAAQBxAREYiI/gcA" }; var img = new Image(); img.onload = function () { var result = (img.width > 0) && (img.height > 0); callback(feature, result); }; img.onerror = function () { callback(feature, false); }; img.src = "data:image/webp;base64," + kTestImages[feature];}

Note that image-loading is non-blocking and asynchronous. This means that anycode that depends on WebP support should preferably be put in the callbackfunction.

Why did Google release WebP as open source?

We deeply believe in the importance of the open source model. With WebP inopen source, anyone can work with the format and suggest improvements. Withyour input and suggestions, we believe that WebP will become even more usefulas a graphic format over time.

How can I convert my personal images files to WebP?

You can use the WebP command line utility to convert your personal image filesto WebP format. See Using WebP for more details.

If you have many images to convert you can use your platform's shell tosimplify the operation. For example, to convert all jpeg files in a folder trythe following:

Windows:

How can I judge WebP image quality for myself?

Currently, you can view WebP files by converting them into a common formatthat uses lossless compression, such as PNG, and then view the PNG files inany browser or image viewer. To get a quick idea of WebP quality, see theGallery on this site for side-by-side photocomparisons.

How do I get the source code?

The converter code is available on thedownloads section of the WebP open-source projectpage. The code for the lightweight decoder and the VP8 specification are onthe WebM site. See theRIFF Container page for the containerspecification.

What is the maximum size a WebP image can be?

WebP is bitstream-compatible with VP8 and uses 14 bits for width and height.The maximum pixel dimensions of a WebP image is 16383 x 16383.

What color spaces does the WebP format support?

Consistent with the VP8 bitstream, lossy WebP works exclusively with an8-bit Y'CbCr 4:2:0 (often called YUV420) image format. Please refer to Section2, "Format Overview"of RFC 6386,VP8 Data Format and Decoding Guidefor more detail.

Lossless WebP works exclusively with the RGBA format. See theWebP Lossless Bitstream specification.

Can a WebP image grow larger than its source image?

Yes, usually when converting from a lossy format to WebP lossless orvice versa. This is mainly due to the colorspace difference (YUV420 vs ARGB)and the conversion between these.

There are three typical situations:

If the source image is in lossless ARGB format, the spatial downsampling to YUV420 will introduce new colors that are harder to compress than the original ones. This situation can typically happen when the source is in PNG format with few colors: converting to lossy WebP (or, similarly to a lossy JPEG) will potentially result in a larger file size.
If the source is in lossy format, using lossless WebP compression to capture the lossy nature of the source will typically result in a larger file. This is not particular to WebP, and can occur when converting a JPEG source to lossless WebP or PNG formats, for instance.
If the source is in lossy format and you are trying to compress it as a lossy WebP with higher quality setting. For instance, trying to convert a JPEG file saved at quality 80 to a WebP file with quality 95 will usually result in a larger file, even if both formats are lossy. Assessing the source's quality is often impossible, so it is advised to lower the target WebP quality if the file size is consistently larger. Another possibility is to avoid using the quality setting, and instead target a given file size using the -size option in the cwebp tool, or the equivalent API. For instance, targeting 80% of the original file size might prove more robust.

Note that converting a JPEG source to lossy WebP, or a PNG source to losslessWebP are not prone to such file size surprises.

Does WebP support progressive or interlaced display?

WebP does not offer a progressive or interlaced decoding refresh in the JPEG orPNG sense. This is likely to put too much pressure on the CPU and memory of thedecoding client as each refresh event involves a full pass through thedecompression system.

On average, decoding a progressive JPEG image is equivalent to decoding thebaseline one 3 times.

Alternatively, WebP offers incremental decoding, where all available incomingbytes of the bitstream are used to try and produce a displayable sample row assoon as possible. This both saves memory, CPU and re-paint effort on theclient while providing visual cues about the download status. The incrementaldecoding feature is available through theAdvanced Decoding API.

How do I use the libwebp Java bindings in my Android project?

WebP includes support for JNI bindings to the simple encoder and decoderinterfaces in the swig/ directory.

Building the library in Eclipse:

Make sure you have the ADT plugin installed along the with NDK tools and your NDK path is set correctly (Preferences > Android > NDK).
Create a new project: File > New > Project > Android Application Project.
Clone or unpack libwebp to a folder named jni in the new project.
Add swig/libwebp_java_wrap.c to the LOCAL_SRC_FILES list.
Right-click on the new project and select Android Tools > Add Native Support ... to include the library in your build.
Open the project properties and go to C/C++ Build > Behaviour. Add ENABLE_SHARED=1 to the Build (Incremental build) section to build libwebp as a shared library.
Note Setting NDK_TOOLCHAIN_VERSION=4.8 will in general improve 32-bit build performance.
Add swig/libwebp.jar to the libs/ project folder.
Build your project. This will create libs/<target-arch>/libwebp.so.
Use System.loadLibrary("webp") to load the library at runtime.

Note that the library can be built manually with ndk-build and the includedAndroid.mk. Some of the steps described above can be reused in that case.

How do I use libwebp with C#?

WebP can be built as a DLL which exports the libwebp API. These functions canthen be imported in C#.

Build libwebp.dll. This will set WEBP_EXTERN properly to export the API functions.
```
libwebp> nmake /f Makefile.vc CFG=release-dynamic
```

Add libwebp.dll to your project and import the desired functions. Note if you use the simple API you should call WebPFree() to free any buffers returned.

[DllImport("libwebp.dll", CallingConvention = CallingConvention.Cdecl)]static extern int WebPEncodeBGRA(IntPtr rgba, int width, int height, int stride, float quality_factor, out IntPtr output);[DllImport("libwebp.dll", CallingConvention = CallingConvention.Cdecl)]static extern int WebPFree(IntPtr p);void Encode() { Bitmap source = new Bitmap("input.png"); BitmapData data = source.LockBits( new Rectangle(0, 0, source.Width, source.Height), ImageLockMode.ReadOnly, PixelFormat.Format32bppArgb); IntPtr webp_data; const int size = WebPEncodeBGRA(data.Scan0, source.Width, source.Height, data.Stride, 80, out webp_data); // ... WebPFree(webp_data);}

Why should I use animated WebP?

Advantages of animated WebP compared to animated GIF

WebP supports 24-bit RGB color with an 8-bit alpha channel, compared toGIF's 8-bit color and 1-bit alpha.
WebP supports both lossy and lossless compression; in fact, a singleanimation can combine lossy and lossless frames. GIF only supportslossless compression. WebP's lossy compression techniques are well-suitedto animated images created from real-world videos, an increasingly popularsource of animated images.
WebP requires fewer bytes than GIF¹.Animated GIFs converted to lossy WebPs are 64% smaller, while losslessWebPs are 19% smaller. This is especially important on mobile networks.
WebP takes less time to decode in the presence of seeking. InBlink, scrolling or changing tabs canhide and show images, resulting in animations being paused and thenskipped forward to a different point. Excessive CPU usage that results inanimations dropping frames can also require the decoder to seek forward inthe animation. In these scenarios, animated WebP takes 0.57x as much totaldecode time² as GIF, resulting in less jankduring scrolling and faster recovery from CPU utilization spikes. This isdue to two advantages of WebP over GIF:
- WebP images store metadata about whether each frame contains alpha,eliminating the need to decode the frame to make this determination.This leads to more accurate inference of which previous frames a givenframe depends on, thereby reducing unnecessary decoding of previousframes.
- Much like a modern video encoder, the WebP encoder heuristically addskey-frames at regular intervals (which most GIF encoders do not do).This dramatically improves seeking in long animations. To facilitateinserting such frames without significantly increasing image size, WebPadds a'blending method' flagfor each frame in addition to the frame disposal method that GIF uses.This allows a keyframe to draw as if the entire image had been clearedto the background color without forcing the previous frame to befull-size.

Disadvantages of animated WebP compared to animated GIF

In the absence of seeking, straight-line decoding of WebP is more CPU-intensive than GIF. Lossy WebP takes 2.2x as much decode time as GIF, while lossless WebP takes 1.5x as much.
WebP support is not nearly as widespread as GIF support, which is effectively universal.
Adding WebP support to browsers increases the code footprint and attack surface. In Blink this is approximately 1500 additional lines of code (including the WebP demux library and Blink-side WebP image decoder). Note that this problem could be reduced in the future if WebP and WebM share more common decoding code, or if WebP's capabilities are subsumed in WebM's.

Why not simply support WebM in <img>?

It may make sense long-term to support video formats inside the <img>tag. However, doing so now, with the intent that WebM in <img> can fillthe proposed role of animated WebP, is problematic:

When decoding a frame that relies on previous frames, WebM requires 50% more memory than animated WebP to hold the minimum number of previous frames³.
Video codec and container support varies widely across browsers and devices. To facilitate automatic content transcoding (e.g. for bandwidth-saving proxies), browsers would need to add accept headers indicating what formats their image tags support. Even this might be insufficient, as MIME types like "video/webm" or "video/mpeg" still don't indicate the codec support (e.g. VP8 vs. VP9). On the other hand, the WebP format is effectively frozen, and if vendors who ship it agree to ship animated WebP, the behavior of WebP across all UAs should be consistent; and since the "image/webp" accept header is already used to indicate WebP support, no new accept header changes are necessary.
The Chromium video stack is optimized for smooth playback, and assumes there's only one or two videos playing at a time. As a result, the implementation is aggressive in consuming system resources (threads, memory, etc.) to maximize playback quality. Such an implementation does not scale well to many simultaneous videos and would need to be redesigned to be suitable for use with image-heavy webpages.
WebM does not currently incorporate all the compression techniques from WebP. As a result, this image compresses significantly better with WebP than the alternatives:

¹ For all comparisons between animated GIF and animated WebP, weused a corpus of about 7000 animated GIF images taken randomly from the web.These images were converted to animated WebP using the 'gif2webp' tool usingdefault settings (built from the latestlibwebp source treeas of 10/08/2013). The comparative numbers are the average values across theseimages.

² The decode times were computed using the latest libwebp + ToTBlink as of 10/08/2013using a benchmark tool. "Decode timewith seeking" is computed as "Decode the first five frames, clear the framebuffer cache, decode the next five frames, and so forth".

³ WebM keeps 4 YUV reference frames in memory, with each framestoring (width+96)*(height+96) pixels. For YUV 4:2:0, we need 4 bytes per 6pixels (or 3/2 bytes per pixel). So, these reference frames use4*3/2*(width+96)*(height+96) bytes of memory. WebP on the other hand wouldonly need the previous frame (in RGBA) to be available, which is4*width*height bytes of memory.

⁴ Animated WebP rendering requires Google Chrome version 32+