The plugin is supposed to be accounting for this by only starting to serve the modern image formats after the head has been printed. The intention is that the original format remains in use in the head for the very reason you describe.
How specifically are you printing your meta tags?
Oh interesting. So we hook into wp_head and try to use get_the_post_thumbnail_url($post_id, 'full') to retrieve the original image. We had been using large previously and were going to try original_image next but read that wouldn’t work either and instead wp_get_original_image_url() is the way forward.
However if the original image uploaded is a .webp or .avif, this isn’t going to produce a .jpg file so we’re going to have to see if we can forcibly produce a .jpg of every uploaded image.
Here’s the function we’re using: https://github.com/WordPress/performance/blob/c42ed688bc3e2790572fa41a885f09de68b0db15/plugins/webp-uploads/helper.php#L289
Note how it is supposed to prevent the modern format from being used while the wp_head action is being done.
That’s really useful thank you. Let me check that out and see what’s going on.
We developed a wp_get_og_attachment_image_url() function as a work around to this issue which creates a JPG version of the attachment and adds it to the attachment meta if it doesn’t exist then returns the URL.
But otherwise the core get_the_post_thumbnail_url() function is incorrectly returning the modern image format?
Are you using a block theme or a classic theme?
Block theme, Twenty Twenty-Two. Here is an example page that now shows the correctly generated image in the <head> og:image <meta> https://ryesussex.uk/events/live-music/doghouse-2/
This is a good example because the original_image was a .webp so I don’t think your plugin would have produced a fallback anyway.
OK, I completely misunderstood your report. The issue isn’t that the original JPEG isn’t being used in the wp_head. The issue is that there was no original JPEG to begin with, because you uploaded a WebP. This plugin does not generate a JPEG if you uploaded a WebP/AVIF. In other words, what you’ve identified is the need for an “Ancient Image Formats” plugin 😀
This might make sense to add to the plugin so that it becomes useful even when a site is using WebP/AVIF from the start, as it could generate fallback JPEG images for the sake of social providers that don’t support modern image formats.
I’ve filed a feature request for you: https://github.com/WordPress/performance/issues/2215
Oh great!
So just to be clear … on a post that has had a .webp image uploaded as the featured image, a call to wp_get_attachment_image_url() within wp_head hook the returned image URL is a .webp. With my wp_get_og_attachment_image_url() wrapper function, this returns a generated .jpg URL that is then stored in the attachment meta for future use.
However … on a post that has had a .jpg image uploaded as the featured image, a call to wp_get_attachment_image_url() within wp_head hook the returned image URL is also a .webp. And again, with my wp_get_og_attachment_image_url() wrapper function, this returns the original .jpg (without having to generate a new one). Let me know if you’d like to see this but I’m sure you have a much better plan.
Anyway, what I’m trying to convey is that both issues are a problem (for us) and I suspect it’s because we are using wp_get_attachment_image_url() rather than get_the_post_thumbnail_url(). This is because we have developed a way to extend taxonomy terms to be able to have a featured image as well as posts and the latter function obviously would not work for us in that scenario.
Perhaps get_the_post_thumbnail_url() could also be included in your exclusion for delivering modern image formats before head has been printed?
Oliver
@domainsupport I just discovered that this is apparently a known issue when calling either wp_get_attachment_image_url() or get_the_post_thumbnail_url(). See my comment.
There is a simple workaround, however. Simply pass the <img> tag through wp_content_img_tag filters like so:
$img = apply_filters(
'wp_content_img_tag',
wp_get_attachment_image( get_post_thumbnail_id(), 'large' ),
'', // Unused context.
get_post_thumbnail_id()
);
echo $img;
This results in the WebP showing up for me when being called in the BODY.
@westonruter Thanks for this. We aren’t seeing an issue in the <body> content though. For us it’s making sure that Open Graph og:image meta in the <head> always shows a .jpeg (or other Open Graph compatible image format).
@domainsupport And that is because you uploaded a WebP to begin with, correct?
@westonruter Yes. But it also happens with all uploaded images (.webp or otherwise) when using get_the_post_thumbnail_url() in wp_head hook. We are using a block theme if that helps.
@domainsupport I’m unable to reproduce the issue. I’m testing in Twenty Twenty-Five.
I’m using this plugin to test: https://gist.github.com/westonruter/8571a91675e1886e34304f8bc76a13fb
In the HEAD, I see:
<meta name="og:image" class="get_the_post_thumbnail_url" content="http://localhost:8000/wp-content/uploads/2025/09/image_32-150x150.jpg">
<meta name="og:image" class="wp_get_attachment_image_url" content="http://localhost:8000/wp-content/uploads/2025/09/image_32-150x150.jpg">
And at the beginning of the BODY I see:
get_the_post_thumbnail_url:
<img src='http://localhost:8000/wp-content/uploads/2025/09/image_32-150x150.jpg'>
wp_get_attachment_image:
<img width="150" height="150" src="http://localhost:8000/wp-content/uploads/2025/09/image_32-150x150.jpg" class="attachment-thumbnail size-thumbnail" alt="" decoding="async" loading="lazy" />
wp_content_img_tag(get_the_post_thumbnail_url):
<img src='http://localhost:8000/wp-content/uploads/2025/09/image_32-150x150-jpg.webp'>
wp_content_img_tag(wp_get_attachment_image):
<img width="150" height="150" src="http://localhost:8000/wp-content/uploads/2025/09/image_32-150x150-jpg.webp" class="attachment-thumbnail size-thumbnail" alt="" decoding="async" loading="lazy" />
the_content(wp_get_attachment_image):
<p><img width="150" height="150" src="http://localhost:8000/wp-content/uploads/2025/09/image_32-150x150-jpg.webp" class="wp-image-619" alt="" decoding="async" loading="lazy" /></p>
So you can see that in HEAD, it is printing JPEG images, whereas WebP images are being served as expected when wp_content_img_tag filters are applied on the IMG tag.
Ah, change line 20 in your plugin to …
$url = wp_get_attachment_image_url( get_post_thumbnail_id(), 'thumbnail' );
Our issue is with wp_get_attachment_image_url() because we are not always using a featured image of a post for the og:image in the <head> but instead we are having to get our own chosen image for a taxonomy term, for example.
Apologies, it looks like I mentioned the wrong function in my earlier messages.
