safari webp support

WebP image format

Image format (based on the VP8 video format) that supports lossy and lossless compression, as well as animation and alpha transparency. WebP generally has better compression than JPEG, PNG and GIF and is designed to supersede them. AVIF and JPEG XL are designed to supersede WebP.

• 4 - 5 : Not supported
• 6 - 8 : Not supported (but has polyfill available)
• 9 - 22 : Partial support
• 23 - 31 : Partial support
• 32 - 122 : Supported
• 123 : Supported
• 124 - 126 : Supported
• 12 - 17 : Not supported
• 18 - 122 : Supported
• 3.1 - 13.1 : Not supported
• 14 - 15.6 : Partial support
• 16.0 - 17.3 : Supported
• 17.4 : Supported
• 17.5 - TP : Supported
• 2 - 3.6 : Not supported
• 4 - 64 : Not supported (but has polyfill available)
• 65 - 123 : Supported
• 124 : Supported
• 125 - 127 : Supported
• 9 - 10.5 : Not supported
• 10.6 - 11 : Not supported (but has polyfill available)
• 11.1 - 11.6 : Partial support
• 12 - 18 : Partial support
• 19 - 108 : Supported
• 109 : Supported
• 5.5 - 10 : Not supported
• 11 : Not supported

Chrome for Android

Safari on ios.

• 3.2 - 13.7 : Not supported
• 14 - 17.3 : Supported
• 17.5 : Supported

Samsung Internet

• 4 - 23 : Supported
• 24 : Supported
• all : Supported

Opera Mobile

• 10 : Not supported
• 11 : Partial support
• 11.1 - 12.1 : Supported
• 80 : Supported

UC Browser for Android

• 15.5 : Supported

Android Browser

• 2.1 - 3 : Not supported
• 4 - 4.1 : Partial support
• 4.2 - 4.4.4 : Supported

Firefox for Android

• 14.9 : Supported

Baidu Browser

• 13.52 : Supported

KaiOS Browser

• 2.5 : Not supported (but has polyfill available)
• 3 : Supported

• Español – América Latina
• Português – Brasil
• Tiếng Việt
• Make the Web Faster

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.

• 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+)
• Google Chrome (desktop) 23+
• Opera 12.10+
• Native web browser, Android 4.2+ (JB-MR1)
• Pale Moon 26+
• Google Chrome (desktop and Android) 32+
• Wikipedia WebP article

How can I detect browser support for WebP?

You'll want to serve WebP images only to clients that can display them properly, and fall back to legacy formats for clients that can't. Fortunately there are several techniques for detecting WebP support, both on the client-side and server-side. Some CDN providers offer WebP support detection as part of their service.

Server-side content negotiation via Accept headers

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

• Deploying New Image Formats on the Web
• Serving WebP Images to Visitors Using HTML Elements

Modernizr is a JavaScript library for conveniently detecting HTML5 and CSS3 feature support in web browsers. Look for the properties Modernizr.webp , Modernizr.webp.lossless , Modernizr.webp.alpha and Modernizr.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 request the first candidate image that it can display properly. See this discussion on HTML5 Rocks . The <picture> element is supported by more browsers all the time.

In your own JavaScript

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

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.

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

Linux / macOS:

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?

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

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

Can a WebP image grow larger than its source image?

Yes, usually when converting from a lossy format to WebP lossless or vice 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 lossless WebP 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 or PNG sense. This is likely to put too much pressure on the CPU and memory of the decoding client as each refresh event involves a full pass through the decompression system.

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

Alternatively, WebP offers incremental decoding, where all available incoming bytes of the bitstream are used to try and produce a displayable sample row as soon as possible. This both saves memory, CPU and re-paint effort on the client while providing visual cues about the download status. The incremental decoding feature is available through the Advanced 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 decoder interfaces 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 included Android.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 can then be imported in C#.

Build libwebp.dll. This will set WEBP_EXTERN properly to export the API functions.

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.

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 to GIF's 8-bit color and 1-bit alpha.

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.

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

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

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

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:

• GIF (85 KB)
• WebM with alpha (32 KB)
• Lossless animated WebP (5 KB) 4

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 YUV 4: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+

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License , and code samples are licensed under the Apache 2.0 License . For details, see the Google Developers Site Policies . Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2023-09-14 UTC.

• Skip to main content
• Skip to search
• Skip to select language
• Sign up for free
• English (US)

Image file type and format guide

In this guide, we'll cover the image file types generally supported by web browsers, and provide insights that will help you select the most appropriate formats to use for your site's imagery.

Common image file types

The image file formats that are most commonly used on the web are listed below.

Note: The older formats like PNG, JPEG, GIF have poor performance compared to newer formats like WebP and AVIF, but enjoy broader "historical" browser support. The newer image formats are seeing increasing popularity as browsers without support become increasingly irrelevant (i.e. have virtually zero market share).

The following list includes image formats that appear on the web, but which should be avoided for web content (generally this is because either they do not have wide browser support, or because there are better alternatives).

Note: The abbreviation for each image format links to a longer description of the format, its capabilities, and detailed browser compatibility information (including which versions introduced support and specific special features that may have been introduced later).

Note: Safari 11.1 added the ability to use a video format, as an animated gif replacement. No other browser supports this. See the Chromium bug , and Firefox bug for more information.

Image file type details

The following sections provide a brief overview of each of the image file types supported by web browsers.

In the tables below, the term bits per component refers to the number of bits used to represent each color component. For example, an RGB color depth of 8 indicates that each of the red, green, and blue components are represented by an 8-bit value. Bit depth , on the other hand, is the total number of bits used to represent each pixel in memory.

APNG (Animated Portable Network Graphics)

APNG is a file format first introduced by Mozilla which extends the PNG standard to add support for animated images. Conceptually similar to the animated GIF format which has been in use for decades, APNG is more capable in that it supports a variety of color depths , whereas animated GIF supports only 8-bit indexed color .

APNG is ideal for basic animations that do not need to synchronize to other activities or to a sound track, such as progress indicators, activity throbbers , and other animated sequences. For example, APNG is one of the formats supported when creating animated stickers for Apple's iMessage application (and the Messages application on iOS). They're also commonly used for the animated portions of web browsers' user interfaces.

AV1 Image File Format (AVIF) is a powerful, open source, royalty-free file format that encodes AV1 bitstreams in the High Efficiency Image File Format (HEIF) container.

Note: AVIF has potential to become the "next big thing" for sharing images in web content. It offers state-of-the-art features and performance, without the encumbrance of complicated licensing and patent royalties that have hampered comparable alternatives.

AV1 is a coding format that was originally designed for video transmission over the Internet. The format benefits from the significant advances in video encoding in recent years, and may potentially benefit from the associated support for hardware rendering. However it also has disadvantages for some cases, as video and image encoding have some different requirements.

The format offers:

• Excellent lossy compression compared to JPG and PNG for visually similar compression levels (e.g. lossy AVIF images are around 50% smaller than JPEG images).
• Generally, AVIF has better compression than WebP — median 50% vs. 30% compression for the same JPG set (source: AVIF WebP Comparison (CTRL Blog)).
• Lossless compression.
• Animation/multi-image storage (similar to animated GIFs, but with much better compression)
• Alpha channel support (i.e. for transparency).
• High Dynamic Range (HDR): support for storing images that can represent bigger contrasts between the lightest and darkest parts of the image.
• Wide Color Gamut: Support for images that can contain a larger range of colors.

AVIF does not support progressive rendering, so files must be fully downloaded before they can be displayed. This often has little impact on real-world user experience because AVIF files are much smaller than the equivalent JPEG or PNG files, and hence can be downloaded and displayed much faster. For larger file size the impact can become significant, and you should consider using a format that supports progressive rendering.

AVIF is supported in Chrome, Edge, Opera, Safari and Firefox (Firefox supports still images but not animations). As support is not yet comprehensive (and has little historical depth) you should provide a fallback in WebP , JPEG or PNG format using the <picture> element (or some other approach).

BMP (Bitmap file)

The BMP ( Bitmap image ) file type is most prevalent on Windows computers, and is generally used only for special cases in web apps and content.

Warning: You should typically avoid using BMP files for website content. The most common form of BMP file represents the data as an uncompressed raster image, resulting in large file sizes compared to png or jpg image types. More efficient BMP formats exist but are not widely used, and rarely supported in web browsers.

BMP theoretically supports a variety of internal data representations. The simplest, and most commonly used, form of BMP file is an uncompressed raster image, with each pixel occupying 3 bytes representing its red, green, and blue components, and each row padded with 0x00 bytes to a multiple of 4 bytes wide.

While other data representations are defined in the specification, they are not widely used and often completely unimplemented. These features include: support for different bit depths, indexed color, alpha channels, and different pixel orders (by default, BMP is written from bottom-left corner toward the right and top, rather than from the top-left corner toward the right and bottom).

Theoretically, several compression algorithms are supported, and the image data can also be stored in JPEG or PNG format within the BMP file.

GIF (Graphics Interchange Format)

In 1987, the CompuServe online service provider introduced the GIF ( Graphics Interchange Format ) image file format to provide a compressed graphics format that all members of their service would be able to use. GIF uses the Lempel-Ziv-Welch (LZW) algorithm to losslessly compress 8-bit indexed color graphics. GIF was one of the first two graphics formats supported by HTML , along with XBM .

Each pixel in a GIF is represented by a single 8-bit value serving as an index into a palette of 24-bit colors (8 bits each of red, green, and blue). The length of a color table is always a power of 2 (that is, each palette has 2, 4, 8, 16, 32, 64, or 256 entries). To simulate more than 255 or 256 colors, dithering is generally used. It is technically possible to tile multiple image blocks, each with its own color palette, to create truecolor images, but in practice this is rarely done.

Pixels are opaque, unless a specific color index is designated as transparent, in which case pixels colored that value are entirely transparent.

GIF supports simple animation, in which following an initial full-size frame, a series of images reflecting the parts of the image that change with each frame are provided.

GIF has been extremely popular for decades, due to its simplicity and compatibility. Its animation support caused a resurgence in its popularity in the social media era, when animated GIFs began to be widely used for short "videos", memes, and other simple animation sequences.

Another popular feature of GIF is support for interlacing , where rows of pixels are stored out of order so that partially-received files can be displayed in lower quality. This is particularly useful when network connections are slow.

GIF is a good choice for simple images and animations, although converting full color images to GIF can result in unsatisfactory dithering. Typically, modern content should use PNG for lossless and indexed still images, and should consider using APNG for lossless animation sequences.

ICO (Microsoft Windows icon)

The ICO (Microsoft Windows icon) file format was designed by Microsoft for desktop icons of Windows systems. However, early versions of Internet Explorer introduced the ability for a website to provide an ICO file named favicon.ico in a website's root directory to specify a favicon — an icon to be displayed in the Favorites menu, and other places where an iconic representation of the site would be useful.

An ICO file can contain multiple icons, and begins with a directory listing details about each. Following the directory comes the data for the icons. Each icon's data can be either a BMP image without the file header, or a complete PNG image (including the file header). If you use ICO files, you should use the BMP format, as support for PNG inside ICO files wasn't added until Windows Vista and may not be well supported.

Warning: ICO files should not be used in web content. Additionally, their use for favicons has subsided in favor of using a PNG file and the <link> element, as described in Providing icons for different usage contexts .

JPEG (Joint Photographic Experts Group image)

The JPEG (typically pronounced " jay-peg ") image format is currently the most widely used lossy compression format for still images. It's particularly useful for photographs; applying lossy compression to content requiring sharpness, like diagrams or charts, can produce unsatisfactory results.

JPEG is actually a data format for compressed photos, rather than a file type. The JFIF ( J PEG F ile I nterchange F ormat) specification describes the format of the files we think of as "JPEG" images.

PNG (Portable Network Graphics)

The PNG (pronounced " ping ") image format uses lossless compression, while supporting higher color depths than GIF and being more efficient, as well as featuring full alpha transparency support.

PNG is widely supported, with all major browsers offering full support for its features.

SVG (Scalable Vector Graphics)

SVG is an XML -based vector graphics format that specifies the contents of an image as a set of drawing commands that create shapes, lines, apply colors, filters, and so forth. SVG files are ideal for diagrams, icons, and other images which can be accurately drawn at any size. As such, SVG is popular for user interface elements in modern Web design.

SVG files are text files containing source code that, when interpreted, draws the desired image. For instance, this example defines an drawing area with initial size 100 by 100 units, containing a line drawn diagonally through the box:

SVG can be used in web content in two ways:

• You can directly write the <svg> element within the HTML, containing SVG elements to draw the image.
• You can display an SVG image anywhere you can use any of the other image types, including with the <img> and <picture> elements, the background-image CSS property, and so forth.

SVG is an ideal choice for images which can be represented using a series of drawing commands, especially if the size at which the image will be rendered is unknown or may vary, since SVG will smoothly scale to the desired size. It's not generally useful for strictly bitmap or photographic images, although it is possible to include bitmap images within an SVG.

TIFF (Tagged Image File Format)

TIFF is a raster graphics file format which was created to store scanned photos, although it can be any kind of image. It is a somewhat "heavy" format, in that TIFF files have a tendency to be larger than images in other formats. This is because of the metadata often included, as well as the fact that most TIFF images are either uncompressed or use compression algorithms that still leave fairly large files after compression.

TIFF supports a variety of compression methods, but the most commonly used are the CCITT Group 4 (and, for older fax systems, Group 3) compression systems used for by fax software, as well as LZW and lossy JPEG compression.

Every value in a TIFF file is specified using its tag (indicating what kind of information it is, such as the width of the image) and its type (indicating the format the data is stored in), followed by the length of the array of values to assign to that tag (all properties are stored in arrays, even for single values). This allows different data types to be used for the same properties. For example, the width of an image, ImageWidth , is stored using tag 0x0100 , and is a one-entry array. By specifying type 3 ( SHORT ), the value of ImageWidth is stored as a 16-bit value:

Specifying type 4 ( LONG ) stores the width as a 32-bit value:

A single TIFF file can contain multiple images; this may be used to represent multi-page documents, for example (such as a multi-page scanned document, or a received fax). However, software reading TIFF files is only required to support the first image.

TIFF supports a variety of color spaces, not just RGB. These include CMYK, YCbCr, and others, making TIFF a good choice for storing images intended for print, film, or television media.

Long ago, some browsers supported TIFF images in web content; today, however, you need to use special libraries or browser add-ons to do so. As such, TIFF files are not useful within the context of web content, but it's common to provide downloadable TIFF files when distributing photos and other artwork intended for precision editing or printing.

WebP supports lossy compression via predictive coding based on the VP8 video codec, and lossless compression that uses substitutions for repeating data. Lossy WebP images are on average 25–35% smaller than JPEG images of visually similar compression levels. Lossless WebP images are typically 26% smaller than the same images in PNG format.

WebP also supports animation: in a lossy WebP file, the image data is represented by a VP8 bitstream, which may contain multiple frames. Lossless WebP holds the ANIM chunk, which describes the animation, and the ANMF chunk, which represents a frame of an animation sequence. Looping is supported.

WebP now has broad support in the latest versions of major web browsers, although it does not have deep historical support. Provide a fallback in either JPEG or PNG format, such as with the <picture> element .

Note: On Safari for macOS, WebP support depends on both Safari and macOS versions. You need Safari 14 or later as well as macOS Big Sur (11) or a more recent version.

XBM (X Window System Bitmap file)

XBM (X Bitmap) files were the first to be supported on the Web, but are no longer used and should be avoided, as their format has potential security concerns. Modern browsers have not supported XBM files in many years, but when dealing with older content, you may find some still around.

XBM uses a snippet of C code to represent the contents of the image as an array of bytes. Each image consists of 2 to 4 #define directives, providing the width and height of the bitmap (and optionally the hotspot, if the image is designed as a cursor), followed by an array of unsigned char , where each value contains 8 1-bit monochrome pixels.

The image must be a multiple of 8 pixels wide. For example, the following code represents an XBM image which is 8 pixels by 8 pixels, with those pixels in a black-and-white checkerboard pattern:

Choosing an image format

Picking the best image format for your needs is likely easier than video formats, as there are fewer options with broad support, and each tends to have a specific set of use-cases.

Photographs

Photographs typically fare well with lossy compression (depending on the encoder's configuration). This makes JPEG and WebP good choices for photographs, with JPEG being more compatible but WebP perhaps offering better compression. To maximize quality and minimize download time, consider providing both using a fallback with WebP as the first choice and JPEG as the second. Otherwise, JPEG is the safe choice for compatibility.

For smaller images such as icons, use a lossless format to avoid loss of detail in a size-constrained image. While lossless WebP is ideal for this purpose, support is not widespread yet, so PNG is a better choice unless you offer a fallback . If your image contains fewer than 256 colors, GIF is an option, although PNG often compresses even smaller with its indexed compression option (PNG-8).

If the icon can be represented using vector graphics, consider SVG , since it scales across various resolutions and sizes, so it's perfect for responsive design. Although SVG support is good, it may be worth offering a PNG fallback for older browsers.

Screenshots

Unless you're willing to compromise on quality, you should use a lossless format for screenshots. This is particularly important if there's any text in your screenshot, as text easily becomes fuzzy and unclear under lossy compression.

PNG is probably your best bet, but lossless WebP is arguably going to be better compressed.

Diagrams, drawings, and charts

For any image that can be represented using vector graphics, SVG is the best choice. Otherwise, you should use a lossless format like PNG. If you do choose a lossy format, such as JPEG or lossy WebP, carefully weigh the compression level to avoid causing text or other shapes to become fuzzy or unclear.

Providing image fallbacks

While the standard HTML <img> element doesn't support compatibility fallbacks for images, the <picture> element does. <picture> is used as a wrapper for a number of <source> elements, each specifying a version of the image in a different format or under different media conditions , as well as an <img> element which defines where to display the image and the fallback to the default or "most compatible" version.

For example, if you're displaying a diagram best displayed with SVG, but wish to offer a fallback to a PNG or GIF of the diagram, you would do something like this:

You can specify as many <source> s as you wish, though typically 2 or 3 is all you need.

• Guide to media types and formats
• Web media technologies
• Guide to video codecs used on the web
• The HTML <img> and <picture> elements
• The CSS background-image property
• The Image() constructor and the HTMLImageElement interface

• a. Send us an email
• b. Anonymous form
• Buyer's Guide
• Upcoming Products
• Tips / Contact Us
• Podcast Instagram Facebook Twitter Mastodon YouTube Notifications RSS Newsletter

WebP Articles

Apple Adds WebP Image Support in Safari 14

Our comprehensive guide highlighting every major new addition in iOS 17, plus how-tos that walk you through using the new features.

App Store changes for the EU, new emoji, Podcasts transcripts, and more.

Get the most out your iPhone 15 with our complete guide to all the new features.

A deep dive into new features in macOS Sonoma, big and small.

Revamped models with OLED displays, M3 chip, and redesigned Magic Keyboard accessory.

Updated 10.9-inch model and new 12.9-inch model, M2 chip expected.

Apple's annual Worldwide Developers Conference will kick off with a keynote on June 10.

Expected to see new AI-focused features and more. Preview coming at WWDC in June with public release in September.

Other Stories

10 hours ago by Tim Hardwick

11 hours ago by Tim Hardwick

11 hours ago by MacRumors Staff

2 days ago by Tim Hardwick

1 week ago by MacRumors Staff

View in English

More Videos

Streaming is available in most browsers, and in the WWDC app.

What's new for web developers

Explore the latest features and improvements for Safari and WebKit. We'll walk you through updated web APIs, CSS and media features, JavaScript syntax, and more to help you build great experiences for people when they use your website, home screen web apps, or embedded WebKit views.

• Have a question? Ask with tag wwdc20-10663
• Safari Release Notes
• Safari Technology Preview
• Search the forums for tag wwdc20-10663
• Web Inspector Reference
• WebKit Open Source Project

Related Videos

• Discover WKWebView enhancements
• Meet Face ID and Touch ID for the web
• Meet Safari Web Extensions
• What's new in Web Inspector

Hello and welcome to WWDC Hello I'm Jon Davis, Web Technologies evangelist for the Safari and WebKit teams.

I'm so excited to get to tell you about all of the new features and improvements for web developers this year. If you develop websites, web apps save to the home screen, or Web content used in apps, and want to learn about all of the latest technologies available in Safari and WebKit, this session is for you. In this session. I'll give you a tour of the new features and enhancements in WebKit and shipping in Safari 13.1 for macOS, Safari on iOS and iPadOS 13.4 and coming to Safari 14 on macOS, iOS an iPadOS. But first, there's some really great news I want to share up front. We made a really big effort this year to improve Safari's interoperability with other browsers. One way to measure that is web platform tests. It's a set of tests used by browser makers to ensure interoperability, so your web content operates the way you expect across browsers. So I'm pleased to announce improved interoperability for service workers, XHR + Fetch, pointer events, CSS, SVG, web assembly, and many more areas. Safari passes a hundred and forty thousand new interoperability test cases this year. And you can look forward to continued progress in this area. But there's so much more to talk about this year. In this session, I'm going to go over performance improvements, lots of new web API, CSS updates, media enhancements, including some great image updates, new JavaScript features, and finally, new platform integration capabilities. So let's get started with performance and specifically, browsing performance. Page load performance is foundational to our browsing experience feeling fast and I'm pleased to report Safari 14 is 13 percent faster, clicking a link to an unvisited site, and up to 42 percent faster clicking a link for recently visited web page. Typing a URL into the search and address bar for a recently visited web page is 52 percent faster. We improved instant back by caching up to 34 percent more pages. PFDs show the first page 60 times faster while downloading. And outside of page load performance, closing unresponsive tabs is down from three and a half seconds to just fifty milliseconds. All of these improvements help users and developers have a faster browsing experience in Safari. And there's performance improvements for developers too. CPU usage while scrolling is three times less. It's buttery smooth with 0 dropped frames. IndexedDB operations are up to 10 times faster. Reduced overhead makes for-of loops of the five times faster based on micro benchmarks. Promises are twice as fast in the jet stream to benchmarks asyncfs test, and optimize JavaScript delete operations are up to twelve times faster. Safari and WebKit are faster than ever. But now I'm going to show you the new Web API added in WebKit and available in Safari. First up, is the Web Animations API. It's long awaited and new in Safari 13.1. It's an API available in JavaScript to directly create and control the playback of CSS animations and transitions. You no longer need to manipulate element properties. And you can query the animations on the page. Seek directly to a specific time in the animation playback cycle or even change the speed and direction of playback. So I've been experimenting with a loading animation of the WebKit logo for an internal website where my colleagues enjoy discussing their pets, and after it's animated in the compass needle spins and it's a really fun element. So I'd like to let folks interact with it a bit by clicking on the logo to give the needle another spin. And with the web animations API it's really easy. So in the logos click handler we use the element.animate method. It takes a keyframe effect parameter that allows us to setup the keyframes for the animation, a nice easing function so the needle starts spinning quickly with a softer ending and then a reasonable duration in milliseconds. And here it is. And clicking the logo keeps the needle spinning. That's more fun than I thought it'd be.

And Web Inspectors Graphics tab now shows you the animation instances.

Including the animations created each time I click the logo. It also visualizes the easing curves and to help with timing, it gives you a perspective of the animation delay compared to its duration. There are lots of updates to Web Inspector you can learn about the What's New in Web Inspector session available in your Developer app. So that's the Web animations API. JavaScript control of animations with all of the power and efficiency of CSS animations and transitions. Next in our tour is ResizeObserver. It's newly available with the release of Safari 13.1 earlier this year. It's a JavaScript API that reports element size changes. It allows elements to respond to the size changes of other elements not just the viewport. With ResizeObserver your content can react to elements that change their size both when the viewport changes like when the window gets resized but more importantly when other changes to size occur, like changing the display property or when new child elements are appended.

My colleagues on the WebKit team love discussing their pets, so I've been maintaining an internal website where they can share pictures and comment on them. And of course it uses responsive design so that when you resize the window and things start to get a little cramped, the control shrink to just show the icon and save space. But some folks said they wanted a flexible editor because they like having the extra space while commenting. You can see it resizes well for the window but it doesn't work when resizing the editor. This hasn't been easily achieved before but ResizeObserver is a great tool for this because it can detect when the size of the container changes and react. Let me show you what I've been working on. So to address this, I'll create a new ResizeObserver in the site's JavaScript that detects when the containers width goes below a certain size then toggle a CSS class on the container. The style rules for our formatting buttons can pick that up and hide the label to use less space and collapse the size of the button so they always fit. To get it working. I just passed the container element to the observer method of my newly constructed ResizeObserver. Let's check it out. With the code in place, the resizing the editor causes the buttons to hide the labels and resize the way you'd expect.

That's ResizeObserver. If you want to learn more, there's a blog post on the WebKit blog with more details. Another feature I need to get working on the Webkitten's website is the paste button, and I've got just the thing. The async clipboard API. It's also new this year and available in Safari 13.1. You can read data from the system clipboard for paste operations or write data to the clipboard for copying. It's asynchronous to avoid blocking the page while you're accessing the clipboard. And there's no need to fake a selection or have element focus to copy data into it. It supports multiple items and item types like images and rich formatted text but, needs a secure context over https and calls must be invoked in response to user interaction.

Now if you're working with just plain text it has shortcut methods to make it even easier. Copying plain text is as easy as using the clipboard right text method to write a string of text. And pasting plain text, uses of the clipboard read text method. But for the WebKittens website the team wants rich HTML formatted text when pasting. Inside the click handler the clipboard read method is called asynchronously to get an array of clipboard items back. The clipboard items are iterated to find the HTML data.

The data gets returned as a blob object. Then file reader is used to get the HTML data back which is collected and appended to the editor.

I copied a comment from another post earlier to test with so I'll click the paste button and post it. And there you have it, a functional paste button that handles rich text. The async clipboard API is powerful and this just scratched the surface. You can learn more about it on the WebKit blog.

Now if you're a developer of a library or framework, this next news is for you.

Safari 13.1 now supports the EventTarget constructor. EventTarget is used by objects that can receive events. For example, Dom elements extend the EventTarget. But now your own objects can too without all the extra element behaviors. Library authors can use native event functionality to create their own object interface for dispatching custom events for non-dom objects. While we're talking about library developers a lot of libraries are simply providing a custom component for web authors to implement. So that leads us to an update on web components.

We've had support for web components in Safari for a long while now and they keep becoming more and more powerful. It's actually another feature I took advantage of on the WebKitten's website.

Everything from the posts, to the comments, and even the formatting buttons are implemented as web components, But for a simple example let's look specifically at the formatting buttons. Some simple template markup is used to setup the component as a custom element. The ID attribute is used to reference this template in JavaScript. Then in JavaScript it's registered as a custom element. The ID attribute value is repurposed to serve as the custom element hook.

Our custom element class extends a generic HTML element and in the constructor clones the template content to modify the template fragment with our text label and icon. And then appends our modified DOM fragment to the shadow root of the custom element. Then the page markup can create those elements using the custom elements registered name as the tag name.

Each of the format buttons can be customized for bold, italic, underline, and so on. Now as a component author you provide a generic component that can get used in many ways so you want to give the page authors some control over how these elements are style. In this case as a component author we don't know what kind of button each one will end up being. In the example, component styling handles the layout of a larger text icon to the left of the button label. But in order to give the bold buttons B icon a bold style and an italic style for the I icon the page author who knows what kind of button they're implementing needs to be able to customize that part of the component.

With Safari 13.1 released this spring they can, using CSS shadow parts. It allows web component authors to specifically expose parts of their components to content authors to style with their own CSS. You don't need to know all of the underlying markup structure of the component to style it, just the parts of the component the author exposed through the part attribute. Component layout is protected and content authors can customize the components to fit the use case or better match the style of their website. Looking back at our example, this was the original template markup. By adding the part attribute to the elements inside the component they're now exposed to the pages CSS. Now the page author that's implementing the buttons can use the part pseudo element selector and easily decorate the buttons to provide an extra visual hint about their function. So this, turns into this. And that's CSS shadow parts for web components. Speaking of visual hints, WebKit added support for another visual hint. The HTML enter key hint attribute it supported on Safari on iOS 13.4 and iPadOS. It allows you to declare an action label for the enter key on virtual keyboards of a touchscreen device. You can set the label to give your users a hint about what action the enter key will take. Instead of just enter it could be done or go or send, for example. Before I wrap up the new Web API, there's one more API to mention, the web authentication API. It supports logging into websites beyond usernames and passwords, and it was introduced in Safari 13 and Safari on iOS 13.3 with support for hardware security keys. And with the latest Safari, WebKit has added support for Touch ID and Face ID in Safari on macOS iOS and iPadOS. You can learn all about the security and convenience of implementing it for your users by watching the Face ID and Touch ID on the web session in the Developer app.

And that's a look at the new Web API in Safari this year: web animations ResizeObserver, the async clipboard API, The EventTarget Constructor,CSS Shadow Parts, HTML. Enter Key Hints and web authentication. I can't wait to see what you do with these new capabilities. But we're not done yet.

Let's take a look at several CSS improvements that give content authors more fine grained control over styles and layout.

This year WebKit added support for system font families. They work in WebKit across all of Apple's platforms. They each map to a system appropriate font.

The system UI font family is a generic alias for UI sans serif and on the system it maps to San Francisco. UI serif uses the New York font family.

UI monospace uses SF Mono. And UI rounded uses SF rounded. They're useful when developing a web app that you want to make feel more familiar to the system and the different font families allow you to create an easily identifiable difference between content and user interface, such as on the WebKit website. It uses UI serif for the content areas And UI sans serif for the user interface when adding a comment. So beautiful new font families for your web apps. Another CSS feature that can help your content layout is support for line break anywhere. It breaks to a new line at any opportunity before the content overflows. This can be particularly helpful with long words that can overflow narrow containers, especially technical jargon like code where hyphenation might change the intended meaning of the word. And it can protect your content from unexpected layout issues. The simplest way to understand it is to see the behavior of the default line break rule. WebKit uses a default line break heuristic that's based on language specific rules while taking into account other CSS that might apply. With Roman-based written languages, the line break heuristic hyphenates the text when it can, but take a look at the first word on this page from the web inspector command line API reference. The long query instances syntax doesn't break at all. It's breaking right before the long word making a blank line after the bullet. Then it still overflows the container and the viewport. Line break anywhere makes it possible to fix this.

With line break anywhere, it breaks T the character just before the overflow making it possible to see all of the content without breaking the layout. Now it's possible to see the entire line. Next up is another powerful CSS tool, the is pseudo-selector. It's newly supported in Safari 14. It matches a list of selectors just like the matches pseudo-selector. In fact is aliases our matches pseudo- selector behavior that's been part of Safari for years. The matching element gets the specificity of the most specific selector. It's really useful for avoiding repetitive selectors. Here's an example. Here a 3em top margin is added to all the headings. Then this rule removes the top margin when a heading is immediately followed by a heading of the next level down. But, of course, if this is used in a content management system, page authors may not adhere to strict rules of an h1 followed by an h2. They're not technically prevented from using an h1 followed by an h3, so this isn't enough to cover all of those cases. To do that you'd need a really repetitive selector like this. That's pretty awful looking. But with is we can simplify writing all of that out and it becomes this. That's so much nicer. To go along with is WebKit also supports the where pseudo-selector. It works the same way as is in that it matches a list of selectors, but the big difference is that the CSS specificity of any matching element is always zero. So it can act as a kind of specificity reset. Here's another example. And I'll start by comparing is first. Looking at this example the is selects an intro class, pull quote, or element with the hero ID and styles the paragraph tag that immediately follows it, to use uppercase text and give it an eye-grabbing look. Later in the styles the page author is trying to specifically override the heading levels two through six followed by a paragraph to use normal text. Seems like they only want this to work for paragraphs following level 1 headings. But using is means that it won't work as expected. This is where the where pseudo-selector comes in. Using where instead makes this possible. Now, the elements matched by where a reset to a specificity level of zero making the follow up rules able to override as expected.

From CSS we move on to media. But included in media is a fair number of image updates as well. And I'm pleased to announce support for an entirely new image format webP images.

WebP is an open source image format that provides smaller file sizes and lots of advance bells and whistles. It supports a lossy format comparable to JPEG and a lossless format like PDG. It even supports transparency and animation across both. In your markup you can use the picture elements to add webP images with a fallback and on the server side you can look at the accept header. But a big reason web developers are excited for this format is the file size savings. This sample JPEG encoded at 80 percent quality is 5.1 megabytes but the webP lossy encoding of the same quality settings gives us a 41 percent file savings with visual quality that's nearly the same as a JPEG. This high resolution PNG weighs in at eight hundred and seventeen kilobytes but the lossless webP encoding preserves the transparency and saves us 33 percent. WebP image support is available in Safari 14 and Safari for iOS 14. While we're talking about images there are a couple of new default image behaviors in WebKit. The first is a change that will improve the way your web pages load. We've all seen what happens when we load a web page where the images load in and cause the layout to jump around.

I'm going to show you how easy it is to fix this with WebKits new behavior for calculating the default image aspect ratio. In Safari 13.1 and in Safari on iOS 13.4, WebKit now calculates the image aspect ratio from an image tags width and height attributes. All you have to do is make sure to add the width and height attributes to your image tags. Let's see what happens when the attributes are added.

There's no jumping around at all. The space is reserved for the image and it just loads right in. Beautiful. The other new default behavior is for image orientation. We've supported respecting EXIF image orientation on iOS for a long time. This update aligns our support on iOS and macOS through the standard image orientation from image value. The from image value tell Safari to respect the image orientation flag encoded into images that support EXIF data. This JPEG image is encoded with an EXIF orientation flag of 6 meaning the camera was rotated 90 degrees counterclockwise. And now you can override this default by setting image orientation value to none to display the image directly as encoded without rotation correction. From images we move on to video. With system support for high dynamic range videos in web content with Safari 14 on macOS.

You can use media queries to detect high dynamic range display support. In CSS you can query support with dynamic range high like this. Or you can use the windows matchMedia method in JavaScript so you can deliver progressively enhanced content to users with HDR displays. Continuing with video updates WebKit has added support for the remote playback API. We've always had an API for doing AirPlay before but the remote playback API is a standards based way of adding remote playback of audio or video to your custom web based media player and sending it to a variety of other remote playback devices like connected TVs, audio-only speakers, and any AirPlay capable devices. To use it, you'll set up a custom button on your video player controls and in response to user interaction call The video elements remote prompt method. Then, you can handle updating remote playback state in your callback handler. It's really that easy. Then on your device, users can tap on the control to get a menu of available remote playback devices. When selected the video is sent to that device. Supporting the remote playback API gives your users the flexibility to enjoy media on all of their devices. And another way to help users enjoy your media is the picture in picture API.

Adding a picture in picture control to your web player allows users to play videos in a pop-out window while they continue doing other tasks. Like remote playback, WebKit has supported picture in picture for a while but the standards based picture in picture API is now available and it works across iOS, iPadOS and macOS. Similar to using the remote playback API you set up a custom control element and call the video elements request picture in picture method in response to user interaction. That's it. Then your users can enjoy videos in picture in picture mode on their device while doing other tasks. In other news related to video, Safari 14 include support for timed metadata in HLS. It's new in Safari 14. And this is metadata synchronized to the media timestamps in the video stream. It can be used to provide program information like episode details or live sports data like inning boundaries or scores. There are two approaches supported, The HLS EXT daterange tag is available in the data queue and carries the metadata to the HLS media playlists themselves. The advantages of using these tags is their immediacy and scope. All metadata in media playlists is available to the video player as soon as it's loaded. It doesn't require waiting for the specific segment to load or for the playhead to pass over it.

And event message boxes are now available in fragmented MP4s. These are compatible with ID3 storage and other formats like MPEG-2 transport streams to carry the same metadata in a fragmented MP4 containers. This is especially important for codecs like HEVC and Dolby Atmos which Apple platforms only recognize inside fragmented MP4s. The last update is an enhancement for developers of video sites that provide subtitles and captioning.

This is a short but sweet update. It's an enhancement to text track you that allows you to use your own captions format but use native caption rendering.

Developers can use existing caption formats without needing to convert them all. And because the user agent is responsible for displaying the captions, they get first class accessibility treatment. Plus they render in both full screen and picture in picture without any extra work. Those are our media updates with support for webP images, new defaults for image aspect ratio and orientation, Mac HDR video, timed metadata in HLS, remote playback, and picture in picture APIs with natively rendered subtitles in captions. Now it's time for new JavaScript features. Starting with BigInts. BigInts are new data types in JavaScript. They're integers that are arbitrarily large and most commonly used in cryptography, but are useful wherever you need numbers larger than the max safe integer in JavaScript. But there are a few things to keep in mind. You can't use number operations or mix operations with the regular number data type. You also can't use JSON.stringifty to serialize a BinInt for backwards compatibility reasons. You'll need to build your own serialization functionality to ensure the decoding process matches your serialization format.

And be aware that when using the division operator, BigInts will drop any decimal values. That's BinInts available in Safari 14. But WebKit also supports some powerful new operators to help with null and undefined values.

The nullish coalescing operator works like other logical operators but it checks for existence. Let's look at a quick example.

So I have a person class where the constructor takes a first name, last name, and age argument. The nullish coalescing operator is used to check if an argument's value is provided. If it's null or undefined, the result of the right-hand side of the operator is used instead.

Here without any arguments the right-hand side defaults as I like to think of them, are used. But passing boolean values, regardless of what they are, pass the existence check and are set as the properties and the person object.

Passing a filled in string or empty string or even zero for the age still evaluates to set the fields to the passed in arguments. And finally passing the full data sets the properties and that's nullish coalescing. Building on nullish coalescing and also new this year is optional chaining. It's a new JavaScript syntax that gives you a shortcut for property access. And it even works for indexes and methods too. Take a look at this example.

Here, we add a name property to include both the first and last name. And when a person is registered we want to see the first name. This is how you might typically add some guards to make sure you can access the first name property.

Passing no arguments to the person when calling register gives us an undefined result.

And passing strings for the first name and last name gives us the expected first name, but with optional chaining, we can replace this approach with new syntax that uses the optional chaining operator. And it works in the exact same way. It also works with indexes like checking for the first entry in an array of a person's children. Using optional chaining here avoids the type error and it even works for methods. Trying to call an undeclared method triggers an error but with optional chaining you can avoid the error. So that's optional chaining. Sticking with the operators theme they're even more newly available operators in Safari 14, Logical assignment operators. And they come in three flavors: logical and assignment, logical or assignment, plus a knowledge assignment operator. Logical assignment operators are nice in that they only evaluate the left-hand side expression once and it isn't as destructive in that it doesn't always reassign. Take this example using the nullish coalescing operator where it always reassigns inner HTML. With a knowledge assignment operator, it only destructively assigns inner HTML if it is null or undefined. Switching gears back to objects for a moment, WebKit in Safari 14 include support for public class fields. Public class fields are new syntax to declare member properties that are part of the object, regardless of them being set up in the constructor. Looking at the person example earlier they could be set up like this. Now, children, for example, will still be available when a new person object is created, even though it isn't set in the constructor. By not having it in the constructor you can focus on the logic instead of worrying if variables are set, as public class fields are guaranteed to always be added. And a final utility in JavaScript to look at is String replaceAll. Finally, String replaceAll is new in Safari 13.1 and it does what it promises, replacing all instances of a string. Previously the string replace method would only replace the first occurrence of the string. You'd have to iterate over the words in the string or use a global regular expression.

With replaceAll you can replace all the instances of the string. And those are the powerful new JavaScript features available in Safari this year: BigInt, Nullish coalescing, optional chaining, Logical assignment operators, Public class fields, and String replaceAll. That's our JavaScript updates.

And finally I'm going to share a few exciting platform integration capabilities new this year.

First up is AR quick look on iOS. These are experiences launched from Safari that can be customized with Web technologies. And new with iOS 13.3, these experiences can include a banner for users to buy products. You can customize individual elements of the banner or provide a completely custom banner with a simple HTML page. To learn more I encourage you to check out the Shop Online with AR Quick Look session in the Developer app.

Another platform technology in Safari updated this year is Apple Pay.

Apple Pay on the web has been updated to add new button types with custom rounded corners and the ability to request redacted billing details.

This is great for merchants that calculate tax based on a customer's location but have no use for the shipping address. To learn more see the What's New in Wallet and Apple Pay session in the Developer app. Finally another experience new this year is app clips. It gives users a focused, fast, and frictionless experience without waiting for downloading and installing an entire app. On your website you can let users know that an app clip interaction is available by adding the Apple iTunes meta tag to your websites HTML and include your App Store ID and the new app clip bundle ID parameter to add a banner to your website. You can learn more about app clips by watching the Explore App Clips session in the Developer app.

That wraps up our platform integration with customizable AR quick look, Apple Pay updates, and the all new app clips experience. And it also wraps up our tour of the new features and improvements of Safari and WebKit.

There's a whole lot new in Safari this year powered by changes in WebKit and I encourage you to try these features out and share your feedback. Now is the perfect time to test it and we'd love to hear how it goes especially if you run into bugs. For Web API, CSS, or JavaScript bugs you can file issues on the Web get bug tracker at bugs.webkit.org. For Safari bugs or issues specific to iOS, home screen web apps, or Apple platform integration features, you can use feedback assistant. If you want to stay on the leading edge of what's coming you should download and use Safari Technology Preview. It's a separate version of Safari that works right alongside of Safari and it's shipped every two weeks with a sneak peek of new and experimental features as well as new web inspector tools. So as a web developer you can be using the latest developer tools every two weeks. You can also stay informed by keeping tabs on the WebKit website at webkit.org. It features blog posts, safari technology preview, release notes, and a fantastic library of reference guides for using web inspector. You can also follow WebKit on Twitter for new announcements about the WebKit project along with tips and tricks for web inspector. And check out the links related to this session including Safari Web Extensions. What's New in Web Inspector and more web technologies. Thanks for joining me and enjoy WWDC.

4:22 - Web Animations API code example

6:43 - Resize observer example

8:15 - Async Clipboard API plain text programmatic copy

8:22 - Async Clipboard API plain text examples

10:25 - Web Component example markup

10:36 - Registering the Web Component

11:02 - Web Component custom elements

12:28 - Original example Web Component template

12:30 - Example Web Component template with CSS Shadow Parts

12:38 - CSS Shadow Part styles

13:16 - HTML enterkeyhint attribute

14:32 - System font families

14:45 - San Francisco font family

14:53 - New York font family

14:58 - SF Mono font family

15:03 - SF Rounded font family

16:07 - line-break: auto

16:43 - line-break: anywhere

17:25 - Removing margins from subsequent headings

17:56 - Removing margins from any subsequent headings

18:02 - Using :is() to remove margins from subsequent headings

18:31 - :is() specificity prevents the override from working

19:07 - :where () resets specificity

19:53 - WebP graceful fallback to JPG

19:54 - WebP graceful fallback to JPG and server-side detection

21:17 - Image with no size attributes

21:19 - Image with size attributes

21:49 - Respect EXIF image orientation default behavior

22:13 - Override image orientation to use the raw image capture

22:37 - HDR display CSS media query

22:42 - HDR display CSS media query and JavaScript matchMedia detection

23:19 - Remote Playback API example

24:20 - Picture in Picture example

27:11 - BigInt example with division examples

28:02 - Nullish coalescing operator

29:09 - JavaScript optional chaining example

29:41 - JavaScript optional chaining example

29:49 - JavaScript optional chaining with indexes

30:02 - JavaScript optional chaining with methods

30:23 - Logical assignment operators

30:44 - Nullish coalescing approach

30:52 - Logical assignment operator

30:53 - Public class fields

31:58 - String.prototype.replace example

32:09 - String.prototype.replaceAll example

33:53 - App Clips banner

Looking for something specific? Enter a topic above and jump straight to the good stuff.

An error occurred when submitting your query. Please check your Internet connection and try again.

WebP Image Support Coming to iOS 14

Apple announced a ton of new updates at yesterday’s WWDC20 keynote address, from new hardware to updated applications. There’s lots to gawk at and enough device-envy to go around.

But there’s one little line in the Safari 14 Beta release notes that caught my eye:

Added WebP image support.

🎉🎉🎉

This excites me because WebP is a super progressive format that encodes images in lossless and lossy formats that we get with other image formats we already use, like JPEG, but at a fraction of the file size. We use WebP right here at CSS-Tricks, thanks to Jetpack and its Site Accelerator feature that serves WebP versions of the images we upload to browsers that support them. Jeremy Wagner has a great write-up on WebP and how to work with it, specifically for WordPress.

So, yes, this means WebP will be largely supported across the board (:IE-sad-trombone:) once Safari 14 ships.

This browser support data is from Caniuse , which has more detail. A number indicates that browser supports the feature at that version and up.

Mobile / Tablet

Even with that great support, defining fallbacks with the <picture> element is still a good idea.

Oh, and not to be completely overshadowed, Safari 14 also squeezes in some CSS goodies, like the :is() and :where() pseudo class functions, which we linked up a couple of weeks ago. Jen Simmons picked out other key features we should be excited about.

Safari 14 Beta Release Notes • Added WebP • Changed to derive <img> aspect ratio from size attributes • Added :is() • Added :where() • Safari no longer supports Flash • Added Safari Web Extensions • Added Webpage Translation (Beta) & much more: https://t.co/qO2Cy7rK4A — Jen Simmons (@jensimmons) June 22, 2020

Direct Link →

Yeah!!!! welcome to a few years back Apple

I’d written up a post on my site nearly 10 years ago, just after WebP had been announced (it was being called “weppy” at the time). I mentioned there was promise with a Safari plugin. It’d been supported until ~2015 https://github.com/nickzman/weppy/releases/tag/v1.0.3

We’ve all been waiting a long time to see Safari support but now that we’re getting it, I’m starting to wonder more about the politics of browsers vs actual tech… https://siipo.la/blog/is-webp-really-better-than-jpeg

Must-read: https://siipo.la/blog/is-webp-really-better-than-jpeg

This has made my day! It’s about time!!!!!

I recently noticed that webp is supported in Firefox, so I set up a script to convert a bunch of png images to webp. The funny thing is, in some cases, a maximally-compressed lossless webp image is bigger than a Zopfli-compressed png. It doesn’t happen often, and Zopfli takes a lot longer to compress a png, but it’s worth looking for.

Following up – one of the things that WEBP does afford is the possibility of animated images that also include transparency (think Gif89a but with full color) https://mathiasbynens.be/demo/animated-webp Can’t wait – Insta, Twitter and every other social will be overrun with better looking motion :)

Kind of wish they’d support webp in Finder MacOS too so we can view the images locally at least.

YES! Agreed. Would love to see that. There’s a Quick Look Plugin I use called “Glance” (it’s on the AppStore) which allows a lot of other previews for a lot of formats that native macOS doesn’t support. Maybe @samuelmeuli would consider adding webp? https://github.com/samuelmeuli/glance/issues/26

DEV Community

Posted on Jun 24, 2020

Safari 14 ships webp support. Are we nearing the end of PNG on the web?

One thing that really stood out to me in the Safari 14 Release Notes was support for webp.

webp is a much more compact image format than PNG, but it offers a lot of the features we need from PNG such as transparency. Webp also has animation support, and is all around a much more advanced image format for the web than some of its predecessors. Safari was very slow to the game.

In most cases webp is also a better option than jpeg. Progressive jpeg, which offers more pleasant rendering options, may still be the right choice in some cases, but in general we may be done with the need to serve different formats to different browsers.

DEV renders webp to Chrome and Firefox, but not to Safari. We save terabytes of expensive bandwidth this way, but the complexity required to render different formats is something we'd be happy to do away with. So I am very happy about this.

Happy coding ❤️

Top comments (31)

Templates let you quickly answer FAQs or store snippets for re-use.

• Email [email protected]
• Location NY
• Education Mount Allison University
• Pronouns He/him
• Work Co-founder at Forem
• Joined Dec 27, 2015

Safari catching up here makes it that much less appealing to continue supporting IE.

• Email [email protected]
• Location India
• Work Full Stack Developer (Part time) at Shriram Yoga Training & Research Society
• Joined Dec 5, 2019

Add animation to comment likes as well 🤣.

@pp will have some comment updates coming soon enough 😊

• Location Poland
• Work Product Designer at Forem (DEV)
• Joined Oct 25, 2019

• Location Kingston upon Thames, London, UK
• Education Modern History, Brasenose College, Oxford
• Pronouns he/they
• Work Freelance consultant; DevRel at Mastodon gGmbH; open to opportunities.
• Joined Dec 30, 2017

I'm impressed you're still doing that. Isn't MS pushing Chromium-based Edge to basically everyone, now - capable of running it, that is...

• Location Colorado
• Education Indiana University && Georgia Tech
• Work Software Engineer
• Joined May 22, 2019

We save terabytes of expensive bandwidth this way, but the complexity required to render different formats is something we'd be happy to do away with.

On one hand I'm sure that practically everyone who uses this site is using a modern browser that will support webp images and in practice no one (or very few people) will be impacted. But on the other hand it feels like only providing webp images may leave some folks behind. From a digital preservation standpoint providing jpegs just feels good cause it's like so unlikely to ever go obsolete as a format. Ancient computers support it and you can pretty much guarantee future ones will continue to support it.

Like I think there's a reason archives still default to JPEG .

Like I said, probably doesn't matter for Dev and it's user base, but it's interesting to think about from a digital preservation standpoint IMO. 😅

That's a very good point! Thanks for bringing this to the discussion.

• Location yyz
• Work Lead, Dev Comms. Catchpoint/WebPageTest™
• Joined Apr 21, 2017

If you're talking about ppl from emerging markets being left behind - I certainly do understand, and a great point. But would you believe that the 1st browser to support webp outside of Chrome 10 yrs ago, was Opera ? The renown client of choice for emerging markets and have been in full support long before everyone else. So the very ppl you might consider being left behind were likely concerned we were left behind - since major browsers only came aboard in late 2018 - now. 🙃

• Location Kaunas, Lithuania
• Joined Sep 27, 2018

Using lossy image format for preservation?

It's less about perfectly preserving the quality of the original and more about ensuring that the data remains decipherable.

Like if you're archiving something that contains charts, a pixel perfect image of the chart is no good if your device can't read the file format. But if it's a JPEG chances are you can still render and understand what it has despite any lossiness.

• Location Portland, OR!
• Education Computer Science Degree
• Work Application Developer at Corista
• Joined Oct 5, 2017

This one kind of depends on how the tooling for handling images changes. I haven't used many of them, but they will need to work seamlessly with webp files so that users can create, view, and export them easily. Until then I think PNG will stick around.

• Location Addis Ababa, Ethiopia
• Education Self-taught
• Work Junior Backend Engineer at ChainWorks Industries
• Joined Nov 30, 2019

It really depends on the image quality of WebP.

JPG is much more compressed than PNG so artifacts and blurriness in pictures is much bigger on JPG than on PNG, when you view the pictures at full size. If WebP has the same quality as PNG then I think it will be very beneficial for everyone to at least offer WebP as a fallback image option, because let's face it, you can't really extinguish PNG. Just look at how enduring the GIF format is for proof.

Similar to how Youtube offers WebM/VP9 videos for browsers along with MP4 in case a browser doesn't support one of them, although in this case we will see more of "Offer WebP first, if that fails, then fall back to PNG".

• Location Berlin
• Work CTO at Sompani
• Joined Feb 29, 2020

Seriously? WebP support now , just as we see AVIF on the horizon? WebP is pretty crappy...

Yeah, this is only great news because expectations for Apple are so low. If they'd introduced this years ago along with the other browsers, we'd already be talking about the next formats.

I mean, I know Safari tends to move at their own pace, but the idea that Safari was grossly late on this? FF support came in 65 (jan 19), Edge (late fall 18). There has been very competent fall back long before that. So in 2 yrs, all the major browser venders (Edge, FF + Safari) outside of Chrome provided support. Considering we've been using JPEGs for almost 30 yrs, I think 2 yrs for webp support is pretty quick.

• Email [email protected]
• Education Master of Computer Applications
• Work Product Manager
• Joined Oct 13, 2019

i was wondering why WebP is crappy? Can you please elaborate about it?

also wondering why webp is crappy.

• Joined Dec 16, 2017

Are there people who still use safari?

iPhone is still the most popular smartphone. Safari desktop isn't getting you very far but iPhone is still big.

I thought Samsung & Huawei and Android are the most popular? Notwithstanding, iPhone is still big. Thanks

I thought Samsung & Huawei and Android are the most popular? Notwithstanding, iPhone is still big.

• Location Helena, Montana, United States
• Work Full Stack Developer
• Joined Dec 3, 2017

Web stats on the sites we run show that mobile Safari is the biggest browser in use, well ahead of all versions of Chrome combined (desktop + Android) which is the second most popular.

So regardless of market share, we see a lot more traffic and users on mobile Safari.

ha. tons. 🙋🏾‍♂️. Safari has a pretty significant mobile presence. An Etsy engineer was just tweeting about this.

• Location Madrid
• Education Telecommunications Engineer
• Work CTO at WITH Madrid
• Joined Feb 16, 2017

I would definitely not target PNG as the first victim, JPEG is outdated and needs to die. Give it another 10 years :)

• Location Japan
• Work Front-end Developer at LINE Corporation
• Joined Aug 10, 2018

For me this was amazing news, especially on animations, animated webp are remarkably smaller than apng

• Email [email protected]
• Location Navi Mumbai
• Work Web Developer at Applied Data Finance
• Joined Jul 1, 2019

How do I get Safari 14 on macOS Mojave ?

maybe if you download STP ( safari tech preview ) and it might be behind a flag. I would check w/ webkit.org. Otherwise, if you will have to download big sur if you want support.

• Location City of Bath, UK 🇬🇧
• Education 10 plus years* active enterprise development experience and a Fine art degree 🎨
• Work Web Development Consultant at ForgeRock
• Joined Aug 21, 2018

What was apples format called again?

• Email [email protected]
• Location Nigeria
• Education Undergraduate
• Pronouns He/Him
• Work Power BI Developer & Business Intelligence Analyst
• Joined Jun 20, 2020

Thank you sir

Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink .

Hide child comments as well

For further actions, you may consider blocking this person and/or reporting abuse

How I Structure my React Projects

phukon - Apr 6

Shared UI Setup For Micro Frontend Application (Module Federation with React) with Nx Workspace

Serif COLAKEL - Apr 6

Como um Portfólio Pode Impulsionar sua Carreira

Klecianny Melo - Apr 4

Using passkeys as a primary login mechanism

Toby Hobson - Mar 19

We're a place where coders share, stay up-to-date and grow their careers.

Find answers, guides, and tutorials to supercharge your content delivery.

• Getting Started
• Account Management
• Troubleshooting

WebP Support

WebP is Google's alternative smaller image format to that of PNG or JPEG. There has been a lot of confusion lately over WebP support and just exactly what you can and cannot use it with, such as browser and CMS support. Today we want to clear up any doubts you might have. WebP support is actually a lot better than what you might think.

WebP support for browsers

Not every browser has WebP support and so it is important to know which ones do as this might affect your decision of whether or not you want to convert and deliver WebP images into your website and or project. Below are all the major browsers and an explanation about WebP support .

As of July 2020, global WebP support from browsers is 79.4% - caniuse

Chrome WebP

Google Chrome has officially had WebP support since Chrome 23 (originally released in November, 2012), and partial support since Chrome 9. Partial support means they didn't support lossless and alpha versions of WebP.

Google's Android Browser has officially had WebP support since 4.2 (originally released in November 2012), and partial support since Android Browser version 4. Google's Chrome for Android browser has had WebP support since Chrome 50.

Safari WebP

Apple's Safari browser, along with their iOS Safari browser, will both have WebP support in Safari 14 and iOS 14 (expected to be released in September, 2020).

Firefox WebP

Mozilla Firefox has officially had WebP support since Firefox 65.0 (originally released in January, 2019).

Mozilla's Firefox for Android has officially had WebP support since Firefox 68 (originally released in July, 2019). Mozilla's Firefox for iOS doesn't have WebP support yet (but that may change once Apple releases support for WebP).

Microsoft Edge has officially had WebP support since version 1809 of Windows (originally released in October, 2018).

Internet Explorer WebP

Microsoft Internet Explorer doesn't have WebP support and it never will because there will be no new versions of the Internet Explorer browser.

Opera has officially had WebP support since Opera 12.1 (originally released in November, 2012), and partial support since Opera 11.5. Partial support means they didn't support lossless and alpha versions of WebP.

Opera's Mini browser officially supports WebP in all current versions.

Should you use WebP?

Since WebP support globally hovers around 80%, it can make a lot of sense to use this image format as an alternative to PNG and JPEG. It is very important to note, that no matter how implement WebP, you are simply serving WebP images to browsers that support it , and then the default format, like PNG and JPEG, to the other browsers. You aren't breaking your images by using WebP. Think of it as an addition, rather than a change. There are also a few other things to consider, such as browser market share, your current traffic, and WebP file sizes as compared to PNG and JPEG.

1. Browser market share

Remember to look at the browser market share when determining whether or not you should use WebP. After many years of development the most commonly used browsers support WebP. We collected some stats from a few different sources as they each collect data in their own unique way.

StatCounter browser market share

According to StatCounter as of June 2020, Chrome holds 65.47% of the market share, Safari 16.97%, and Firefox 4.25%.

W3Counter browser market share

According to W3Counter , as of June 2020, Chrome holds 63% of the market share, Safari 14.4%, and Firefox 5.1%.

W3Schools browser market share

According to W3Schools , as of May 2020, Chrome holds 80.7% of the market share, Firefox 8.5%, and Safari 4.1%. These statistics are measured by the monthly visits W3Schools receives.

Clicky browser market share

According to Clicky , as of July 2020, Chrome holds 62.92% of the market share, Safari 14.44%, and Firefox 7.71%.

After looking at the data above, Chrome on average holds about 68% of the browser market share . It is important to realize if you add WebP images to your project, a majority of visitors will indeed see the WebP versions. Once Apple releases Safari 14 and iOS 14, which will add support for WebP, it will make a significant increase in global WebP support.

2. Google Analytics

Now just because the browser market share might be leaning towards Chrome for most people, it doesn't necessarily mean your website or application is the same. It is always very important to confirm these numbers, which can easily be done in your Google Analytics. In our example below you can see that almost 70% of the traffic is coming from Chrome. So in this scenario, WebP could be very beneficial, as it means 70% of the visitors are going to be delivered incredibly smaller file sizes.

And don't forget about mobile! As you can see in our example a majority of the traffic comes from Apple devices. Once iOS 14 gets full WebP support it will be a dramatic difference for a lot of mobile traffic.

3. WebP file sizes

We have already written a couple case studies on comparing WebP file sizes with those of PNG and JPEG. Make sure to check them out.

• WebP resulted in a 85.87% decrease in average image size. Our load times decreased by 11% and total page weight decreased by 29%.
• WebP resulted in a 42.8% decrease in average image size. Our load times decreased by 3% and total page weight decreased by 25%.
• WebP Case Study with WordPress Cache Enabler

There is also the cost-benefit ratio to consider. For CMS systems such as WordPress, you now have two images instead of one, a PNG or JPEG and a WebP image. So using WebP will take up more of your disk space on your server. But the fact of the matter is smaller image file sizes lead to faster website load times.

The savings in traffic should also not be forgotten. Depending on the project, a tidy sum can quickly accumulate. Having to deliver fewer bytes ultimately means that the server has to shoulder a smaller burden.

Automatic WebP conversion

In May, 2019 we released our powerful Image Processing service that is capable of converting images to WebP. Combined with our Cache Key WebP feature we can automatically convert and deliver by our global network WebP formatted images when accepted.

WebP CMS support

Then comes the issue of platform support, whether you are using a CMS like WordPress or Joomla, or simply a static site with a PHP framework like Laravel. Below we will explain a bit about how to serve up WebP images in the various platforms.

WordPress WebP

WordPress is actually quite easy to implement WebP support. You can use our Optimus image optimizer plugin to automatically convert your images to WebP when they are uploaded to your WordPress media library.

Then you can use our free Cache Enabler plugin to serve up the WebP images to your visitors.

The important part is that Cache Enabler actually determines the browser support and delivers WebP to supported browsers, and then PNG and or JPEG to the other browsers. It is actually doing all of the switching for you automatically.

Magento WebP

The free WebP Magento extension by Yireo allows you to enable WebP support if the browser supports it. Browser support for WebP is detected based on a simple User-Agent check and an additional JavaScript detection. If WebP is detected, the extension will parse the HTML output of the Magento root-block to make sure links to supported images are actually replaced with WebP images.

WebP on other platforms

For other platforms, make sure to read our post on how to deliver WebP . Some platforms will require a tweak to your .htaccess file or Nginx config file to enable WebP support.

As you can see, when it comes to WebP support, it is probably much more supported than you originally thought. You definitely have to take browser market share and data from your current traffic into consideration. If over 70% of your traffic for example is coming from Google Chrome, then it makes a lot of sense to use WebP to speed up your website. And if you are on a CMS, it is quite easy because there are plugins that can handle the conversion and automatic switching from PNG or JPEG to WebP.

Image Processing

Our powerful real-time Image Processing feature transforms and optimizes your images with simple query parameters. Your image management workflow defines the user experience by transforming and optimizing the image delivery for any browser. Process…

How WebP Compression Works

We've talked a lot about WebP and how it's beneficial for improving load times by reducing image sizes without sacrificing quality. However, we haven't yet gone into detail about how WebP compression actually works. There are various techniques at…

WebP Converter - Online File Conversion

Google's WebP image format, particularly lossless WebP, can a be a great solution when it comes to dramatically decreasing the size of your images, while still retaining the quality. We saw an 85% decrease in image size when converting from JPG to…

Supercharge your content delivery 🚀

Try KeyCDN with a free 14 day trial, no credit card required.

• Learn about our solutions
• View all of our integrations
• See how we compare
• Learn about our company
• Ask us a question
• Learn about our Partner Program
• Search our partner database
• Login to your Partner Portal
• Login to your Partner Control Panel
• Support Portal
• ImageEngine FAQs

All Top 5 Browsers Support WebP In 2021 Q2

WebP is no longer a new wave image file format. It’s supported by all five of the top mobile browsers including Chrome Mobile, Mobile Safari, Chromium, Samsung Browser, Facebook on Android, and more. The great news for eCommerce and B2C companies is that ImageEngine automatically reformats images to the proper file format for the fastest image delivery possible, including WebP of course!

Websites and eCommerce sites are adopting image optimization to provide superior web performance, particularly on mobile devices. Resizing, compressing, and converting images to nextgeneration formats generates images up to 80% smaller than their original size.

WebP was not always seen as the most efficient next-generation image format. Prior to Safari version 14, JPEG 2000 was the most efficient next-generation image format supported by Apple’s Safari browser. However, Safari version 14, released September 2020, started to support WebP. WebP image format was already supported by Chrome (and its Chromium derivatives), the world’s most popular mobile browser, starting back in 2014 with version 32.

[Image CDNs](https://imageengine.io/features/what-is-an-image-cdn/ “Image CDN”) automatically convert images to next-generation formats, including WebP, JP2 (JPEG 2000), and AVIF. ImageEngine will convert to images to the most efficient format supported by the device and browser. We studied millions of image format conversions performed by the ImageEngine.io [image CDN](https://imageengine.io/features/what-is-an-image-cdn/ “image CDN”).

WebP has increased by 26 percentage points from 2020 to 2021. 71% of all traffic is now delivered in WebP format. This increase is driven by Safari’s adoption of WebP in version 14 released September 2020. The remaining 13% of images using JP2 are delivered to Safari browser versions prior to 14.

More articles you may be interested in.

Optimize Your Images and Boost Your Site with ImageEngine’s Free Developer Program

Imageengine’s sustainable journey: commitment, achievements, and vision for the future, jpeg xl: a new era for image optimization, the importance of image optimization for web seo.

Session expired

Please log in again. The login page will open in a new tab. After logging in you can close it and return to this page.

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

webP Support Safari on macOS Mojave

Will Apple Safari on macOS Mojave ever fully integrate webP and webM support?

It's a pity! You can use webP in an outdated Firefox Version and it renders great. Why does Apple still keep users away using webP. I do not want to switch to Firefox/Chrome. More websites starting to serve webp files and Safari won't show any images.

Posted on Aug 4, 2021 5:23 AM

Loading page content

Page content loaded

Aug 4, 2021 10:17 AM in response to Tom Binroth

Isn't the webP webM Google? This may explain your conundrum as the battle continues.

WebP   is a modern image format that provides lossless & lossy compression for images on the web.

You can convert these if necessary.

You can open a WEBM file with most modern web browsers, like Google Chrome, Opera, Firefox, and Edge.

If you want to play WEBM files in the Safari web browser on a Mac, you can do so through  VLC for Mac OS X plugin. If your web browser isn't opening the WEBM file, make sure it's fully updated.

or search the app store:

you can submit your user feedback: https://www.apple.com/feedback/macos.html

Aug 4, 2021 12:47 PM in response to Tom Binroth

Tom Binroth wrote:

Right, most modern web browsers show webP files, except Safari.

I am looking for native webP/webM support in Safari and macOS Mojave Safari.

Apple already implemented webP/webM support to Safari for iOS and macOS Big Sur.

I do not want to convert images. I would like to view website.

Right. Update your software, the current is macOS 11.5.1

Update macOS on Mac - Apple Support

Aug 4, 2021 1:00 PM in response to leroydouglas

leroydouglas wrote:

Too bad. Unfortunately MacPro5,1 does not support Big Sur.

Aug 4, 2021 1:10 PM in response to Tom Binroth

Your alternative is to upgrade your hardware.

Apple | Trade in

It never pays to get too far behind in the hardware or software, as you are experiencing now.

Aug 4, 2021 12:41 PM in response to leroydouglas

I am looking for native webP/webM support in Safari and macOS Mojave Safari. Apple already implemented webP/webM support to Safari for iOS and macOS Big Sur. webP and webM is getting a wide spread standard which exist around 10 years.

Aug 4, 2021 3:23 PM in response to leroydouglas

I have switched to Brave Browser.

Microsoft PowerToys now lets you peek at WebP files, my most-hated type of file

What you need to know.

• Microsoft PowerToys is a collection of utilities that enhance the Windows experience.
• The app just received an update to version 0.80.0, which includes several improvements and fixes.
• Among the highlights is added support for WebP, WebM, and audio files when using the Peek utility.

Microsoft PowerToys is arguably the best free app on Windows 11. The collection of utilities gets new features and improvements regularly, and April is no exception. You can now download PowerToys v0.80.0 through GitHub or the Microsoft Store .

The update allows winget to configure PowerToys and fixes several UI issues. It also adds support for the Peek feature to look at WebP, WebM, and audio files. The full change log is quite extensive, as is often the case for PowerToys.

The Peek feature in PowerToys lets you preview files without having to open multiple separate applications. You just need to configure a shortcut to take a peek at any supported file (CTRL+SPACE is the default shortcut). Since Peek supports images, videos, and now audio files, you can preview all those files with a single shortcut rather than having to open different apps. Pressing an arrow key lets you browse through the file previews, which is handy for quickly checking content.

PowerToys | Free at GitHub | Free at Microsoft Store

This collection of utilities includes a large library of features to enhance the Windows experience. PowerToys is designed with power users in mind, but it has handy features for people who just use their PC for everyday computing too. View Deal

What is a WebP file?

Our colleagues over at Tom's Hardware have a breakdown of the history of WebP files and why websites use them, but I'll summarize some of the key points here. As the name suggests, WebP files were invented with the web in mind. You have Google to thank for WebP, as the company introduced the file type in 2010.

WebP files are designed to reduce load times for websites. They compress better than JPEG files by between 25-34%, according to Google . Despite Google's involvement of introducing and supporting WebP files, other companies are on board. Apple's Safari supports WebP, as do Chromium browsers and some other browsers.

For several years, WebP files required a plugin to work in Photoshop, but that's no longer the case . Most photo editing apps support WebP files in 2024. Many of those apps can convert WebP files into other formats easily.

So, if many big companies are on board and my browser of choice works with WebP files, why do I hate them? Because some images appear to be a different file format but then when you try to save them, they turn out to be WebP files. I then have to convert the files into the format I want, creating an extra step to use the image. It's probably a rather specific struggle that myself and the rest of the Windows Central team deal with, so it may not affect your workflow.

PowerToys v0.80.0 change log

• New feature: Desired State Configuration support, allowing the use of winget configure for PowerToys. Check the  DSC documentation  for more information.
• The Windows App SDK dependency was updated to 1.5.1, fixing many underlying UI issues.
• WebP/WebM files support was added to Peek. Thanks  @davidegiacometti !
• Audio files support was added to Peek. Thanks  @davidegiacometti !
• Automated UI testing for FancyZones Editor was added to CI.
• Added a Quick Access entry to access the flyout from PowerToys' tray icon right click menu. Thanks  @pekvasnovsky !
• Added support for Desired State Configuration in PowerToys, allowing the use of winget configure to configure many settings.
• Fix an issue causing the "Keep screen on" option to disable after Awake deactivated itself.

Color Picker

• Fixed a UI issue causing the color picker modal to hide part of the color bar. Thanks  @TheChilledBuffalo !

Command Not Found

• Now tries to find a preview version of PowerShell if no stable version is found.
• Fixed a crash loading the editor when there's a layout with an empty name in the configuration file.
• Refactored layout internal data structures and common code to allow for automated testing.
• The pressing of the shift key is now detected through raw input to fix an issue causing the shift key to be locked for some users.

File Explorer add-ons

• Fixed a crash occurring in the Monaco previewer when a file being previewed isn't found by the code behind.
• Fixed an issue in the Markdown previewer adding a leading space to code blocks. Thanks  @Aaron-Junker !
• Fixed wrong location and scaling of preview results on screens with different DPIs.
• Added better clean up code to thumbnail handlers to prevent locking files.

File Locksmith

• Allow multiple lines to wrap when viewing the modal with selected file paths. Thanks  @sanidhyas3s !
• Fixed the final directory name of the PowerToys Run VSCode Workspaces plugin in the installation directory to match the plugin name. Thanks  @zetaloop !
• Used more generic names for the bootstrap steps, so that "Installing PowerToys" is not shown when uninstalling.

Keyboard Manager

• Fixed an issue that would clear out KBM mappings when certain numpad keys were used as the second key of a chord.
• Added a comment in localization files so that translators won't translate "Text" as "SMS".
• Added support to .WebP/.WebM files in the image/video previewer. Thanks  @davidegiacometti !
• Added support for audio files. Thanks  @davidegiacometti !
• Fixed an issue causing the open file button in the title bar to be un-clickable. Thanks  @davidegiacometti !
• Fixed an issue when previewing a folder with a dot in the name that caused Peek to try to preview it as a file. Thanks  @davidegiacometti !

PowerToys Run

• Added a setting to the Windows Search plugin to exclude files and patterns from the results. Thanks  @HydroH !
• Fixed an issue showing thumbnails caused by a hash collision between similar images.
• Added the "checkbox and multiline text box" additional property type for plugins and improved multiline text handling. Thanks  @htcfreek !

Quick Accent

• Added the Schwa character to the Italian character set. Thanks  @damantioworks !

Registry Preview

• Allow alternative valid names for the root keys. Thanks  @e-t-l !
• Fixed an issue causing many pick file windows to be opened simultaneously. Thanks  @randyrants !

Screen Ruler

• Updated the measure icons for clarity. Thanks  @Aaron-Junker  and  @niels9001 !

Shortcut Guide

• Updated the Emoji shortcut that is shown to the new Windows key + period (.) hotkey.

Text Extractor

• Fixed issues creating the extract layout on certain monitor configurations.

Video Conference Mute

• Added enable/disable telemetry to get usage data.
• Added locks to some terms (like the name of some utilities) so that they aren't localized.
• Fixed some shortcuts not being shown properly in the Flyout and Dashboard. Thanks  @davidegiacometti !
• Updated image for Color Picker and outdated animations for utilities in OOBE. Thanks  @niels9001 !

Documentation

• Added FastWeb plugin to PowerToys Run thirdPartyRunPlugins.md docs. Thanks  @CCcat8059 !
• Removed the old security link to MSRC from the create new issue page, since security.md is already linked there.
• Added clarity regarding unofficial plugins to the PowerToys Run thirdPartyRunPlugins.md docs.

Development

• Updated System.Drawing.Common to 8.0.3 to fix CI builds after the .NET 8.0.3 upgrade was released.
• Adjusted the GitHub action names for releasing to winget and Microsoft Store so they're clearer in the UI.
• Upgraded WinAppSDK to 1.5.1, fixing many related issues.
• Consolidate the WebView2 version used by WinUI 2 in the Keyboard Manager Editor.
• Unified the use of Precompiled Headers when building on CI. Thanks  @dfederm !
• Added UI tests for FancyZones Editor in CI.
• Added a GitHub bot to identify possible duplicates when a new issue is created. Thanks  @craigloewen-msft !
• Updated the WiX installer dependency to 3.14.1 to fix possible security issues.
• Changed the pipelines to use pipeline artifacts instead of build artifacts. Thanks  @dfederm !
• Added the -graph parameter for pipelines. Thanks  @dfederm !
• Tests in the pipelines now run as part of the build step to save on CI time. Thanks  @dfederm !

Release Notes for Safari Technology Preview 192

Apr 10, 2024

by Jon Davis

Safari Technology Preview Release 192 is now available for download for macOS Sonoma and macOS Ventura. If you already have Safari Technology Preview installed, you can update it in System Settings under General → Software Update.

This release includes WebKit changes between: 276247@main…276863@main .

Authentication

Resolved issues.

• Fixed setting the cancel flag once the cancel completes regardless of a subsequent request occurring. ( 276368@main ) (124727713)

New Features

• Added support for View Transitions. ( 276426@main ) (123128491)
• Fixed setting white-space to a non-default value dynamically on a whitespace or a new line. ( 276277@main ) (92559818)
• Fixed the proximity calculation for implicit @scope . ( 276345@main ) (124640124)
• Fixed the Grid track sizing algorithm logical height computation avoid unnecessary grid item updates. ( 276633@main ) (124713418)
• Fixed any @scope limit making the element out of scope. ( 276359@main ) (124956673)
• Fixed the contrast of Menu and MenuText system colors. ( 276597@main ) (125270664)
• Fixed keeping the shorthand value for CSS gap as-is in serialized and computed values. ( 276794@main ) (125335787)

Deprecations

• Removed WEBKIT_KEYFRAMES_RULE and WEBKIT_KEYFRAME_RULE in CSSRule. ( 276264@main ) (97084520)
• Removed the SVGAnimateColorElement interface. ( 276683@main ) (122586568)
• Fixed certain text being duplicated or misplaced. ( 276317@main ) (123642870)
• Fixed word completion suggestion interfering with a website’s suggestion results. ( 276344@main ) (124727588)
• Fixed Object.groupBy and Map.groupBy to work for non-objects. ( 276736@main ) (125485685)
• Fixed Array.fromAsync to not call the Array constructor twice. ( 276752@main ) (125509304)
• Added support for MSE in workers. ( 276389@main ) (123052315)
• Fixed scrolling for an element when a video element with pointer-events: none is placed over it. ( 276807@main ) (118936715)
• Fixed allowing a video’s currentTime to be further than the gap’s start time. ( 276761@main ) (124186726)
• Fixed sampleRate and numberOfChanges to be required and non-zero in a valid AudioEncoderConfig. ( 276413@main ) (125107934)
• Fixed media elements appending the same media segment twice. ( 276821@main ) (125386530)
• Fixed adjusting the size of the scrollable area when changing betwen non-overlay and overlay scrollbars. ( 276439@main ) (117507268)
• Fixed flickering when showing a layer on a painted background for the first time by avoiding async image decoding. ( 276513@main ) (117533495)
• Fixed line breaking before or between ruby sequences. ( 276353@main ) (122663646)
• Added support for URL.parse() . ( 276656@main ) (125376520)
• Added support for shadowRootDelegatesFocus and shadowRootClonable to <template> . ( 276631@main ) (125401993)
• Fixed URL text fragment directives not fully stripped from JavaScript. ( 276370@main ) (107326333)
• Fixed inserting a <picture> element displaying the same image twice. ( 276754@main ) (123795045)

Web Extensions

• Updated to use the web extension architecture in open-source WebKit code. Web extension authors are encouraged to test your extensions and report issues. (123908710)

Web Inspector

• Fixed console clearing unexpectedly when Web Inspector reopens. ( 276705@main ) (124171190)

Apple touts major 60% leap in Safari and WebKit performance

Apple’s WebKit team has published a new blog post this week detailing how they’ve made significant upgrades to Safari’s performance over the last several months. The improvements come following the debut of Speedometer 3.0 in March, described as a “major step forward in making the web faster for all.”

Back in March, Apple, Google, and Mozilla teamed up to launch the new Speedometer 3 browser benchmark. The goal of Speedometer 3 is to “create a shared understanding of web performance so that improvements can be made to enhance the user experience.”

The results provided by Speedometer 3 offer more details on how the test “captures and calculates scores, show more detailed results and introduce an even wider variety of workloads.” Apple says:

The introduction of Speedometer 3.0 is a major step forward in making the web faster for all, and allowing Web developers to make websites and web apps that were not previously possible.

Apple’s WebKit team says that it has successfully improved Safari’s Speedometer 3.0 score by ~60% between the release of Safari 17.0 in September and Safari 17.4’s release in March. These improvements, Apple says, mean that developers can build websites and web apps that are faster than ever before:

With all these optimizations and dozens more, we were able to improve the overall Speedometer 3.0 score by ~60% between Safari 17.0 and Safari 17.4. Even though individual progressions were often less than 1%, over time, they all stacked up together to make a big difference. Because some of these optimizations also benefited Speedometer 2.1, Safari 17.4 is also ~13% faster than Safari 17.0 on Speedometer 2.1. We’re thrilled to deliver these performance improvements to our users allowing web developers to build websites and web apps that are more responsive and snappier than ever.

The full blog post has a ton of technical details on the work that has been done to optimize WebKit and Safari for Speedometer 3.0.

Follow Chance :  Threads ,  Twitter ,  Instagram , and  Mastodon . 

FTC: We use income earning auto affiliate links. More.

Check out 9to5Mac on YouTube for more Apple news:

Chance is an editor for the entire 9to5 network and covers the latest Apple news for 9to5Mac.

Tips, questions, typos to [email protected]