Image distortion since WordPress 6.8, previously correct image now blurry

[doobmanager]

After updating to WordPress 6.8, a previously correctly displayed PNG image now appears blurry and visually distorted on the frontend.
The same image displays perfectly fine on my live site, which is still running WordPress 6.7.

There have been no changes to the theme (BeTheme) or any plugins. The issue started immediately after the 6.8 update and persists even when all plugins are deactivated on the staging site.

The image was added using a standard <img> tag inside an HTML block. It is not a background image or icon font – just a regular PNG file.

Since all other images are displayed correctly, this seems to be a specific rendering issue introduced in WordPress 6.8.

Please check if recent changes in image handling (e.g. attributes like decoding, fetchpriority, or related rendering updates) could be causing this.

Thank you for looking into this!

Best regards
Michelle Obermaier

[doobmanager]

See attached screenshot: wunschbox-render-bug.png

[doobmanager]

Screenshot 2 = Correct display in WP 6.7 (live-site)

[jorbin]

hi @doobmanager, welcome to WordPress Trac.

I'm unable to replicate this issue. You mentioned that you are seeing this with an html block. I attempted to replicate this using the twentytwentyfive theme with the following content in that block.

<p>This is a p with an img tag inside of it <img src="http://jorbintesting.kinsta.cloud/wp-content/uploads/2025/04/MY1A0489-scaled.jpg" width="100%" alt="white flowers on a tree with a blue sky"/> </p>

[fsgroupit]

Replying to jorbin:

hi @doobmanager, welcome to WordPress Trac.

I'm unable to replicate this issue. You mentioned that you are seeing this with an html block. I attempted to replicate this using the twentytwentyfive theme with the following content in that block.

<p>This is a p with an img tag inside of it <img src="http://jorbintesting.kinsta.cloud/wp-content/uploads/2025/04/MY1A0489-scaled.jpg" width="100%" alt="white flowers on a tree with a blue sky"/> </p>

We're seeing this with PNG images, JPG, WEBP seem to be OK. No issues in 6.7, only since 6.8.

[doobmanager]

Thanks for looking into this!

After further testing, I updated the staging site to WordPress 6.8.1 – the issue was still present.
However, after re-uploading the same PNG file and replacing the image URL inside the HTML block, the image is now rendered correctly again.

So it seems the issue may be related to how existing image paths (or metadata) are handled after the 6.8 update, rather than a general rendering bug.

Thanks again for your time and support!

Best regards,
Michelle

[wildworks]

It's very strange that existing images would be blurred. If anyone is experiencing this issue, please let me know the following:

• Does the image have issues in the media library or block editor as well?
• Could you provide the HTML of the image as it is rendered on the front end?

[doobmanager]

Thanks again for your response – I’ve now tested everything carefully and can also answer your earlier questions:

Media Library / Block Editor:
The image looked completely fine in the media library and block editor – the blurriness only occurred on the frontend, not in the backend.

HTML of the image (before re-upload):

<img class="transparent" src="https://staging.suesse-tiere.com/wp-content/uploads/2025/01/wunsch-und-beschwerdebox.png" alt="https://staging.suesse-tiere.com/wp-content/uploads/2025/01/wunsch-und-beschwerdebox.png">

To verify this issue further, I also activated and updated the same two plugins on the live site:

• WP STAGING PRO – Backup Duplicator & Migration (v6.1.3)
• WP STAGING – WordPress Backup Plugin (v4.1.3)

However, the image continued to display correctly on the live site – even with both plugins active and after updating directly to WordPress 6.8.1.

The key difference seems to be that the staging site was originally updated to 6.8.0, where the issue first occurred.
Even after updating to 6.8.1 later, the image stayed blurry until I manually re-uploaded it.

So my current assumption is that something introduced in WP 6.8.0 may have affected how existing images or metadata were handled, and this wasn’t retroactively fixed in 6.8.1 unless the image was replaced.

Hope this helps clarify everything!

Best regards

[wildworks]

The image looked completely fine in the media library and block editor – the blurriness only occurred on the frontend, not in the backend.

This is very interesting. Does anyone know if 6.8 has changed the way images are rendered on the frontend?

[wildworks]

Related ticket: #63448

[SirLouen]

@doobmanager can you check in Tools > Site Health > Info > Media Handling, your ImageMagick version number and version string?

[Bjorn2404]

I'm seeing a similar issue with both WEBP and PNG images and did notice a difference with "Imagick version" on the 6.8 site. The problematic one with WordPress 6.8 is on 3.8.0 whereas the working normally site on WordPress 6.7 has Imagick 3.7.0. I see the issue with the auto resized versions of the images only and can see the loss of quality even in a direct link to the image URL itself vs. front-end output on a page, etc.

[doobmanager]

@SirLouen

Thank you for your follow-up and the request regarding the image editor configuration.

Here are the media handling details from the affected staging site (where the issue originally occurred):

• Active image editor: WP_Image_Editor_Imagick
• Imagick version: 3.7.0
• ImageMagick version: ImageMagick 6.9.12-98 Q16 x86_64
• GD library: Enabled (not active)
• GD version: 2.3.3

Let me know if you need anything else!

Best regards

[SirLouen]

@doobmanager @Bjorn2404 can you test my patch to see if this is the same issue as #63448

​https://github.com/WordPress/wordpress-develop/pull/8813.diff

Just in case you don't know how to add the patch, some little instructions:

1. Go to this file: wp-includes/class-wp-image-editor-imagick.php
2. Comment the line 509 like this:

// $this->image->quantizeImage( $max_colors, $this->image->getColorspace(), 0, false, false );

3. Comment the line 515 like this

// $this->image->setOption( 'png:format', 'png8' );

4. And test again uploading the images

[siliconforks]

Replying to SirLouen:

1. Go to this file: wp-includes/class-wp-image-editor-imagick.php
2. And simply comment the line 509 like this:

// $this->image->quantizeImage( $max_colors, $this->image->getColorspace(), 0, false, false );

3. And test again uploading the images

Actually, I think that the steps above might not work because I suspect this particular issue is elsewhere in the code.

However, your patch ​https://github.com/WordPress/wordpress-develop/pull/8813.diff will probably fix the issue.

[siliconforks]

This is an example of an image that WordPress 6.8.1 does not handle well.

[siliconforks]

If I upload the above attached file grayscale-test-image.png to a WordPress 6.8.1 site, then the resized thumbnails appear black.

[SirLouen]

Replying to siliconforks:

Replying to SirLouen:

1. Go to this file: wp-includes/class-wp-image-editor-imagick.php
2. And simply comment the line 509 like this:

// $this->image->quantizeImage( $max_colors, $this->image->getColorspace(), 0, false, false );

3. And test again uploading the images

Actually, I think that the steps above might not work because I suspect this particular issue is elsewhere in the code.

However, your patch ​https://github.com/WordPress/wordpress-develop/pull/8813.diff will probably fix the issue.

Yes, its true
I seem to be an special use-case of not-Indexed a GrayScale image

The current script is filtering out Grayscale images and indexing them by default. This image will trigger both depht (1bit) + Grayscale comparisons (Colorspace: Gray). Ultimately the Quantization part will be executed twice, ending with a Quantized image with just 2 colors.

And as you say, only commenting the line I proposed is not enough, I have updated my message to also comment another line for testing purposes

My patch solves all use-cases including non-indexed grayscale images like this (but I'm not sure if they know how to apply the patch, so I filtered down to a simpler version just for testing purposes)