Using the picture element

The HTML picture element allows you to provide several versions of an image and let the browser select a format it supports.

For example, you could offer AVIF first, WebP second, and JPEG as a fallback:

<picture>
  <source srcset="/images/example.avif" type="image/avif">
  <source srcset="/images/example.webp" type="image/webp">
  <img src="/images/example.jpg" alt="Example image" width="800" height="600" loading="lazy">
</picture>

The browser examines the type attributes and selects the first format it supports. If none of the sources are suitable, the image specified by the img element is used.

This is generally the simplest approach for supporting multiple image formats in HTML because it requires no PHP processing, HTTP redirects, or browser detection.

The img element also provides the image's alternative text and can specify its dimensions to help prevent layout shifts while the page loads.

Detecting WebP support using the Accept header

For dynamically served images, the HTTP Accept request header can be used to determine which formats a client explicitly accepts.

For example, a browser might send:

Accept: image/avif,image/webp,image/png,image/*,*/*;q=0.8

This indicates that the client accepts several image formats, including AVIF and WebP.

In PHP 8, you can check whether the header explicitly contains image/webp using str_contains():

$accept = $_SERVER['HTTP_ACCEPT'] ?? '';

if (str_contains($accept, 'image/webp')) {
    echo 'The Accept header contains image/webp.';
}

This is only a quick check for the presence of image/webp, not a complete way to determine whether WebP is acceptable. For example, it also matches image/webp;q=0, which explicitly rejects the format.

A production implementation should interpret quality values and wildcards such as image/* rather than rely on substring matching alone. An accepted media type also does not guarantee that the client can process every feature of the format.

Converting and saving a JPEG file

The following example converts a WebP image to JPEG, places it on a white background, and saves it on the server:

$source = '/var/www/mysite/images/example.webp';
$destination = '/var/www/mysite/images/example.jpg';

$image = imagecreatefromwebp($source);

if ($image === false) {
    throw new RuntimeException('Unable to load WebP image');
}

$jpeg = imagecreatetruecolor(imagesx($image), imagesy($image));

if ($jpeg === false) {
    throw new RuntimeException('Unable to create JPEG canvas');
}

$white = imagecolorallocate($jpeg, 255, 255, 255);
imagefill($jpeg, 0, 0, $white);
imagecopy($jpeg, $image, 0, 0, 0, 0, imagesx($image), imagesy($image));

if (!imagejpeg($jpeg, $destination, 80)) {
    throw new RuntimeException('Unable to save JPEG image');
}

The third argument to imagejpeg() specifies the output quality, ranging from 0 to 100. A value of 80 is often a reasonable starting point, although the best setting depends on the image.

One important difference between WebP and JPEG is that JPEG does not support transparency. If the original image contains transparent areas, you need to place it on a background color before converting, as shown above.

Also note that PHP's GD Library does not support decoding animated WebP files with imagecreatefromwebp(). Animated images require a different conversion approach.

Outputting a converted image directly

Instead of saving the converted image, you can deliver it directly to the client. After creating $jpeg as shown above, replace the file-saving step with:

header('Content-Type: image/jpeg');

if (!imagejpeg($jpeg, null, 80)) {
    throw new RuntimeException('Unable to output JPEG image');
}

exit();

In this case, the converted JPEG image is sent directly in the HTTP response without creating a separate file.

Technically, this can work even if the requested URL ends with .webp, because HTTP clients normally use the response's Content-Type to determine the format.

However, delivering JPEG data from a URL ending in .webp may confuse users and applications that rely on file extensions.

It is usually better to serve the JPEG from its own URL or use a format-neutral endpoint when performing dynamic content negotiation.

Why use a 307 redirect?

The 307 Temporary Redirect status code indicates that the requested resource is temporarily available at a different URL.

Unlike a permanent redirect, it does not instruct clients to treat the alternative URL as the permanent location of the resource.

A 307 response also preserves the original HTTP method when the client follows the redirect. For ordinary image requests using GET, a 302 redirect will often behave similarly, but 307 has more explicit method-preservation semantics.

For format-specific redirection, a temporary redirect can be useful because the destination may depend on the client's capabilities rather than a permanent change to the resource's location.

However, be careful with caching. If the redirect depends on the HTTP Accept header, your caching configuration must account for that variation. Otherwise, a redirect intended for one client could incorrectly be reused for another.

Content negotiation and caching

If your application serves different image formats from the same URL based on the client's Accept header, the response should generally include:

Vary: Accept

This informs compatible caches that the response may change depending on the request's Accept header.

Without appropriate cache handling, a proxy or CDN could serve a JPEG response to a client expecting WebP, or serve a WebP response to a client that cannot decode it.

When using separate URLs such as example.webp and example.jpg, this type of content negotiation is usually unnecessary.