Images in srcset are not resized


I’m working on a small site where speed is critical because customers tend to reside in countries with slow Internet connections.

So, to display images, I set up the <picture> element with several <source> elements serving both webp and avif via srcset and sizes.

When I tested the setup with RespImageLint (RespImageLint), on a staging server, I was told that the images did not have the correct size:

… and so on for every image.

Although the file names indicate that the image had been cropped, e.g., 350x-q70.avif, the actual file size was the same as the original image (1200px x 700px).

Here’s a live example with a single image on the page: Case Study

I read before, that for the newer image formats ImageMagick was needed, so that’s what I added to config.php:

return [
    'thumbs' => [
        'driver' => 'im'

The issue appears on both localhost (WampServer with PHP 8.0.13) and Cloudways. I just checked, Cloudways does support ImageMagick:

PHP 8.0.x Extensions […] imagick (module version 3.4.x)

Is there anything I could check to get to the source of this issue?



1 Like

If no resizing or cropping takes place, then your images driver doesn’t seem to work. Note that you might have to provide the path to the convert binary as described in the documentation.

That makes sense. But how do I find the correct path to the driver?

Also, do I need to remove the generated thumbnails manually? These have the correct file names (but the wrong size), so they might not be generated again if already present on disk.

You can do

which convert

on the command line (Mac, Linux), don’t know about Windows.

That would make sense. You can remove the complete media folder.

which convert worked fine on Windows using Git Bash.

I’ll test everything tomorrow or on Monday.

Thanks for your help!

A quick update:

which convert did actually not work on Windows and just returned and unrelated file with the name ‘convert’.

I then found out that ImageMagick wasn’t even installed on my local WampServer, so I installed the driver using this guide: Install the ImageMagick PHP extension in Windows | mlocati - Michele Locati

I verified the installation was successful by running the provided test script at the bottom of that page.

The problem is, even after deleting the media/ folder, I cannot get the images resized.

Is there a way, to determine that Kirby is actually using ImageMagick?



What you installed is PHP Imagick, a PHP extension for working with ImageMagick, which is what you really need. ImageMagick you can install from here:

For Kirby, the PHP Imagick extension is not required. Kirby uses the exec command to execute the convert command when using the im driver.

Oh, I didn’t know that.

So, all I need to do is install ImageMagick from and that (for Kirby) PHP Imagick is not needed?

By the way, the reason I’m trying to install ImageMagick is that I want to convert to webp and avif files (using PHP 8.0).


Just on a side note: Seems that the latest GD versions (PHP 8.1.0) support AVIF: GD: AVIF image support - PHP 8.1 • PHP.Watch

Being able to just use the latest GD version would indeed be perfect. Unfortunately, Cloudways, the provider where this website will be hosted, does not yet support PHP 8.1: PHP Compatibility on Cloudways Platform | Cloudways Help Center

OK, so next I will install ImageMagick directly and see how it goes.

Again, thanks a lot for your help!

I installed ImageMagick from

During installation, I checked this optional checkbox:

Install legacy utilities (e.g. convert)

I did this because of this comment on Stack Overflow:

Since it is version 7.x, there is a checkbox at the time of installation that says ‘Install legacy utilities (e.g. convert)’. You need to select that checkbox during installation.
image - How to use ImageMagick command line on Windows? - Stack Overflow

Next, I verified that the path was set correctly:

Unfortunately, not setting the path in config.php as well as setting it like this:

'thumbs' => [
        'driver' => 'im',
        'bin' => 'D:\Program Files\ImageMagick-7.1.0-Q16-HDRI\convert.exe'

didn’t make a difference.

When inspecting the media folder for a given page, all I could see was a hidden .jobs folder containing several JSON files representing the thumbs that should have been created, but weren’t, e.g.:
media pages with hidden jobs folder


Did I overlook something?




I just tested <?= $image->resize(300) ?> without setting driver or bin in config.php.

The image is indeed resized and appears in the media folder.

Can you run convert on the command line successfully?

Yes, it’s working:

Version: ImageMagick 7.1.0-25 Q16-HDRI x64 2022-02-16
Copyright: (C) 1999-2021 ImageMagick Studio LLC

What if you just set the driver to im without providing the path?

I got ImageMagick to work on the staging server, partly, at least.

After asking Cloudways support for the path to ImageMagick, I set up the site-specific configuration like this:

'thumbs' => [
        'driver' => 'im',
        'bin' => '/usr/bin/convert'

During testing, I found that jpeg and avif files are converted fine, but conversion to webp doesn’t work at all.

For example, here are three links from a <picture> element. When you click on these, you’ll find, that the webp one shows the image in full size (1200px x 700px)




In summary, these are the issues I’m trying to wrap my head around:

  • Localhost (Windows 10): Cannot get ImageMagick to work at all
  • Cloudways: ImageMagick works, except for webp.



Wow, now ImageMagick is working on localhost! I was sure I tried this option before, but apparently I didn’t.

Thanks a lot!

Now, the only question that remains it: Why is webp not converted on the server?

Do you have any idea why this might be the case?

Could it be the supported version? This is the version Cloudways has installed:

PHP 8.0.x Extensions
imagick (module version 3.4.x)
Which Base Packages are Deployed With a Cloudways Server? | Cloudways Help Center

UPDATE: As you said, imagick is just a wrapper around ImageMagick, so the above version number doesn’t tell us much.

OK, I finally found out why the jpegwebp conversion wasn’t working on the server.

Turns out this had to set up manually, as Cloudways support told me:

This is to inform you that The customer provide us the extensions that they are looking to convert into webp so that we may exclude these from Nginx. So we don’t add rules in nginx, only exclude the file types. This way, the images will be rewritten by Apache and served as WebP and the rest of the static files will still be served by NGINX

So, after this setup, webp conversion is working fine.

Again, thank you so much for your help!

1 Like