WebP

Frequently Asked Questions

What is WebP? Why should I use it?

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

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

Which web browsers natively support WebP?

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

  • WebP lossy support
    • Google Chrome (desktop) 17+
    • Google Chrome for Android version 25+
    • Opera 11.10+
    • Native web browser, Android 4.0+ (ICS)
  • WebP lossy, lossless & alpha support (libwebp v0.2.0)
    • Google Chrome (desktop) 23+
    • Google Chrome for Android version 25+
    • Opera 12.10+
    • Native web browser, Android 4.2+ (JB-MR1)

Also see the Wikipedia WebP article.

How can I detect browser support using Javascript?

One possibility is attempting to decode a very small WebP image that uses a particular feature, and check for success. Here is an 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 any code that depends on WebP support should preferably be put in the callback function.

Why did Google release WebP as open source?

We deeply believe in the importance of the open source model. With WebP in open source, anyone can work with the format and suggest improvements. With your input and suggestions, we believe that WebP will become even more useful as 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 files to WebP format. See Using WebP for more details.

How can I judge WebP image quality for myself?

Currently, you can view WebP files by converting them into a common format that uses lossless compression, such as PNG, and then view the PNG files in any browser or image viewer. To get a quick idea of WebP quality, see the Gallery on this site for side-by-side photo comparisons.

How do I get the source code?

The converter code is available on the downloads section of the WebP open-source project page. The code for the lightweight decoder and the VP8 specification are on the WebM site. See the RIFF Container page for the container specification.

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?

WebP uses the color spaces supported by the VP8 bitstream. Please refer to the first paragraph of "2. Format Overview" in the VP8 Bitstream Guide.

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

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

Building the library in Eclipse:

  1. Make sure you have the ADT plugin installed along the with NDK tools and your NDK path is set correctly (Preferences > Android > NDK).
  2. Create a new project: File > New > Project > Android Application Project.
  3. Clone or unpack libwebp to a folder named jni in the new project.
  4. Add swig/libwebp_java_wrap.c to the LOCAL_SRC_FILES list.
  5. Make sure Android.mk is set to build a shared library: include $(BUILD_SHARED_LIBRARY)
  6. Right-click on the new project and select Android Tools > Add Native Support ... to include the library in your build.
  7. Add swig/libwebp.jar to the libs/ project folder.
  8. Build your project. This will create libs/<target-arch>/libwebp.so.
  9. Use System.loadLibrary("webp") to load the library at runtime.

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

Why should I use animated WebP?

Advantages of animated WebP compared to animated GIF

  1. WebP supports 24-bit RGB color with an 8-bit alpha channel, compared to GIF's 8-bit color and 1-bit alpha.

  2. WebP supports both lossy and lossless compression; in fact, a single animation can combine lossy and lossless frames. GIF only supports lossless compression. WebP's lossy compression techniques are well-suited to animated images created from real-world videos, an increasingly popular source of animated images.

  3. WebP requires fewer bytes than GIF1. Animated GIFs converted to lossy WebPs are 64% smaller, while lossless WebPs are 19% smaller. This is especially important on mobile networks.

  4. WebP takes less time to decode in the presence of seeking. In Blink, scrolling or changing tabs can hide and show images, resulting in animations being paused and then skipped forward to a different point. Excessive CPU usage that results in animations dropping frames can also require the decoder to seek forward in the animation. In these scenarios, animated WebP takes 0.57x as much total decode time2 as GIF, resulting in less jank during scrolling and faster recovery from CPU utilization spikes. This is due 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 given frame depends on, thereby reducing unnecessary decoding of previous frames.

    • Much like a modern video encoder, the WebP encoder heuristically adds key-frames at regular intervals (which most GIF encoders do not do). This dramatically improves seeking in long animations. To facilitate inserting such frames without significantly increasing image size, WebP adds a 'blending method' flag for 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 cleared to the background color without forcing the previous frame to be full-size.

Disadvantages of animated WebP compared to animated GIF

  1. 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.

  2. WebP support is not nearly as widespread as GIF support, which is effectively universal.

  3. 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 fill the proposed role of animated WebP, is problematic:

  1. When decoding a frame that relies on previous frames, WebM requires 50% more memory than animated WebP to hold the minimum number of previous frames3.

  2. 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.

  3. 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.

  4. WebM does not currently incorporate all the compression techniques from WebP. As a result, this image compresses significantly better with WebP than the alternatives:


1 For all comparisons between animated GIF and animated WebP, we used a corpus of about 7000 animated GIF images taken randomly from the web. These images were converted to animated WebP using the 'gif2webp' tool using default settings (built from the latest libwebp source tree as of 10/08/2013). The comparative numbers are the average values across these images.

2 The decode times were computed using the latest libwebp + ToT Blink as of 10/08/2013 using a benchmark tool. "Decode time with seeking" is computed as "Decode the first five frames, clear the frame buffer cache, decode the next five frames, and so forth".

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

4 Animated WebP rendering requires Google Chrome version 32+

Authentication required

You need to be signed in with Google+ to do that.

Signing you in...

Google Developers needs your permission to do that.