safari webp support

• 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 2024-04-15 UTC.

• Skip to main content
• Skip to search
• Skip to select language
• Sign up for free

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

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

Import and Export locations on Google Maps

Aneeqa Khan - May 1

Lazy Loaded Video Component in React 🦥🎥

Matt Lewandowski - May 8

7 Tips to Choosing the Right Website Development Platform

Syed Balkhi - Apr 19

What is a 400 Bad Request?

Sohail Pathan - Apr 23

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

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.

Safari 14 removes Flash, gets support for breach alerts, HTTP/3, and WebP

After the flashy presentations of WWDC 2020, Apple has now published more details about some of the new features that are coming to some of its products.

While Safari didn't get too much of the spotlight at WWDC, Safari 14, scheduled to be released later this fall with iOS 14 and macOS 11, is a release that is packed choke-full with features.

WebExtensions API

The biggest and most important of the new additions is support for WebExtensions, a technology for creating browser extensions.

The WebExtension API was initially developed for Chrome but has since been also adopted to Firefox, Opera, Vivaldi, and Edge, and has become the universal standard for creating cross-browser add-ons using common technologies like HTML, JavaScript, and CSS.

What this means for Safari users is that starting this fall, they'll see a huge influx of new Safari extensions as add-on developers are expected to port their existing Chrome and Firefox extensions to work on Apple's browser as well.

Apple said that, for now, WebExtensions will only be available for Safari on macOS.

No more Flash Player

Safari 14 is also an end of an era, as this will be the first version of Safari that won't support Adobe Flash Player content.

Flash Player is scheduled to reach end-of-life on December 31, 2020 , and will be removed from other major browsers as well.

But while old stuff is being removed, new stuff is also being added. One of the new technologies added to Safari is support for HTTP/3 , a new web standard that will make loading websites faster and safer.

Currently, according to W3Techs, most of today's websites are loaded either via HTTP/1.2 or HTTP/2.0, but HTTP/3 is slowly gaining ground, with HTTP/3 support being already present on 6% of all internet sites .

With adoption rates growing and after HTTP/3 made it into Chrome, Firefox, Edge, and others, Safari was expected to add HTTP/3 support in order to keep in sync with its rivals.

Another important addition in Safari is support for WebP , a lightweight image format that has been gaining widespread adoption across the internet.

The format, created by Google, serves as an alternative to the older JPEG format, and Safari has been the last browser to add support for it .

Breach alerts

But Safari hasn't been lagging behind other browsers just in terms of HTTP/3 and WebP support. Apple has also added support for another cool feature, namely breach alerts, already present in both Chrome and Firefox.

Starting this fall, Apple says that Safari 14 will scan a user's locally-stored passwords and show a prompt if one or more of the user's credentials are present in publicly available lists of breached accounts.

Users will be asked to change their passwords, and the Safari prompt will take users directly to each website's change password page -- if publicly known.

Face ID or Touch ID web authentication

In addition, Apple is also adding support for Face ID and Touch ID authentication inside Safari.

Starting with Safari 14, if a website supports WebAuthn-based authentication, Safari will let users use their fingerprint or face to log into online accounts via their browsers.

Until today, Face ID and Touch ID have been used as a user authentication method for native apps only.

SMS OTP autofill

Another feature added to Safari on iOS is support for the new SMS one-time passcode (OTP) format.

As ZDNet reported earlier this year, the feature originated in the Safari team and has recently gained Google's support .

Once it ships with Safari, OTP codes sent to users' devices via SMS will be automatically filled inside the Safari browser as a security measure against certain phishing attacks that can bypass two-factor authentication.

New Privacy Report button

And last but not least, Apple is also adding a Privacy Report button to Safari's toolbar.

The new button doesn't do much except show statistics about the number of trackers Apple's proprietary Intelligent Tracking Prevention system has blocked on each website the user is visiting.

The Privacy Report button is more of a marketing stunt to make users remember that Safari also blocks tracking scripts. The button was most likely added after both Mozilla and Chrome added content blocking features to their respective browsers; however, to be fair, Apple rolled out Intelligent Tracking Prevention long before its two rivals.

WWDC 2020: Apple Silicon highlights in pictures

Arc browser is now available for windows and it's so much better than chrome, adobe wants your help finding security flaws in content credentials and firefly, 5 ways arc browser makes browsing the web fun again.

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

Similar questions

• Issues with Safari on Mojave 10.14.5 Safari doesn't want to work. I just did a Re-Install of the iOS. I have a hard wired Internet connection as well as wifi network. I'm getting 70mbps Download and 6 Mbps Upload speeds. Firefox is working flawlessly on my 2012 MacBook Pro. I am getting annoyed with this. I can't find any information on how to Fix this after 5 hours of Google searching. Is there a new version of Safari that ISN"T tied into Mojave 10.14.5 that I have to sacrifice a Goat to get? The Big issue is that sometimes Safari works fine. But then it doesn't want to load the websites that it's been going to for the last couple of years. 409 4
• how do I put chrome browser on my MacBook Air with OS Mojave? how do I put chrome browser on my MacBook Air with OS Mojave? 461 2
• Can I have another browser like Firefox concurrently while I still use Safari 10.1.2 on my MacBook Pro 13" retina (early 2015 model) Can I have another browser like Firefox concurrently installed and ready for use while I still use Safari 10.1.2 on my MacBook Pro 13" retina (early 2015 model) 371 15

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.

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

Apple adding WebM audio codec support to Safari with iOS 15

Apple today released the fifth beta of iOS 15 to developers . As we get closer to the final release next month, the update brought only a few minor changes to the operating system. However, one interesting detail about the latest iOS 15 beta is that it adds support for the WebM audio codec to Safari.

The feature is considered experimental and can be enabled or disabled by going to Safari’s advanced settings. 9to5Mac was able to confirm through the iOS 15 beta 5 internal code that this option should come enabled by default from now on.

The WebM audio codec is part of the open media file format created by Google in 2010, which also includes the WebM video codec and WebP image extension. Apple has never been interested in adopting the WebP and WebM formats in the past, as Steve Jobs once said that Google’s codecs were “a mess.”

The company has finally added support for WebP images to Safari with iOS 14 and macOS Big Sur. Another update to Safari 14 on macOS also added support for the WebM video codec , but this was never added to the iOS version of Safari. Now, with the WebM audio codec available in iOS, it’s probably only a matter of time before Apple adds WebM video support to its mobile operating system.

iOS 15 features a new version of Safari that has been completely redesigned with a floating navigation bar on the iPhone and a new tab bar on the iPad. The new design has been considered quite controversial, and multiple changes have already been made to it since the first beta of iOS 15.

The update is expected to be released for all users this fall. You can try out the iOS 15 beta by joining the Apple Beta Software Program .

• Roundup: Here’s what’s new in iOS 15 beta 5
• Apple inviting macOS Big Sur and Catalina users to try out the new Safari 15 beta
• Apple releases latest iOS 15 public beta with Safari changes and more
• Apple releases Safari Technology Preview 128 with updated tab interface
• Concept: Rethinking Safari in iOS 15 with the same core design principles and goals

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

Check out 9to5Mac on YouTube for more Apple news:

Filipe Espósito is a Brazilian tech Journalist who started covering Apple news on iHelp BR with some exclusive scoops — including the reveal of the new Apple Watch Series 5 models in titanium and ceramic. He joined 9to5Mac to share even more tech news around the world.

Manage push notifications