Using WebP images with a fallback source for incompatible browsers

3 min readFeb 7, 2021

We were recently working on a client project, where — for the first time — they requested the use of WebP images over the more conventional JPEG, PNG formats we are all familiar with.

We had gone through the usual pre-flight testing before handing over — both browser and hardware based — until a chance final testing session on a physical iPad running iOS 13 (more importantly, iOS Safari 13), showed us that none of the images were loading.

The output, oddly, looked as if images could not be found — but we knew they existed and could be found because we could see them across both the local and staging environments on a number of other devices, meaning we needed to dig a bit further to understand the problem.

Can I Use (February 2020) shows almost entire global support for WebP except for Internet Explorer (surprise, surprise), KaiOS — though that was not a concern for the client — and every version of Safari except for the most recent version.

For reference, Safari 13.1 is the latest version available on macOS Catalina and iOS Safari 13.7 is the latest version running on iOS 13. Both of which, granted, are not the latest releases available (macOS Big Sur & iOS 14) but they are nevertheless still widely used and in this instance would need to be catered for.

For our images referenced via the <img> tag, there was a really elegant solution to the problem using the <picture> and <source> tags.

Instead of referencing the resource simply by writing:

<img src="/images/file-name.webp" />

We could simply adapt our code to the following:

<picture>
    <source srcset="/images/file-name.jpg" />
    <img src="/images/file-name.webp" />
</picture>

So far, so good. The next issue to tackle was the background images within our CSS. Our first instinct was to try a typical fallback solution like you might for SVGs, which looked something like this:

.bg-image {
    background-image: url('/images/background.jpg');
    background-image: url('/images/background.webp'), linear-gradient(transparent, transparent);
}

The problem here is that WebP is not SVG, and linear gradients have support throughout all browsers, including those we needed to target. At best, this was trying our last known best solution to a similar problem, at worst, this was a lazy developer attempt at trying to find the quickest way of overcoming a problem without properly investigating it.

After some time researching, the actual solution required a sprinkling of JavaScript and actually took inspiration from the no-js/js conundrum that modernizr has for years helped to solve. By creating a custom build, that exclusively detects WebP support, we could pivot on a no-webp class to load JPEGs where WebP would not work.

This required a little mark-up change to our HTML, but nothing groundbreaking.

<!DOCTYPE html>
<html class="no-webp">
    <head>...</head>
    <body>...</body>
</html>

Using this technique meant we could conditionally load JPEGs over WebP within our CSS. If the users browser supported WebP, the modernizr script would replace the no-webp class with a webp class instead.

.bg-image {
    background-image: url('/images/background.webp');
}.no-webp {
    .bg-image {
       background-image: url('/images/background.jpg');
    }
}

And that is it — and is exactly how we provided the client with a website entirely driven with WebP images, whilst also providing a JPEG/PNG fallback for any browsers that (surprisingly, or not) do not support it.

Using WebP images with a fallback source for incompatible browsers

Written by Ascend

Responses (2)