Repository navigation
Some webp images sizes are not calculated correctly (1px) #2468
Description
Bug Description
Sometimes, webp images are displayed at 1x1 px. In the medla library and on the website. When I open the image URL in a new tab it is displayed correctly.
The first image has width and height equal to 1px in the HTML:
Additional Context
- Wordpres Version : 6.9.4
- PHP Version: 8.1.34
- Plugin Version: Modern Image Formats 2.6.1
Activity
westonruter commentedon May 7, 2026
Can you share share the URL to the original JPEG which was resulted in this 1x1 pixel WebP?
ligne13 commentedon May 14, 2026
Here it is. Thank you.
adamsilverstein commentedon May 18, 2026
Hi @ligne13 thanks for the bug report.
A few questions:
Only the first image?
ligne13 commentedon May 19, 2026
It happens randomly. I was not able to reproduce the bug with the same image. I trizd to upload from the library and from the block editor and it worked this time.
I was just referring to the first image in the list in the screenshot of the Media library.
MarcinDudekDev commentedon Jun 4, 2026
Thanks for the report and the sample image, @ligne13. A few notes that might help narrow this down — and one quick check that would tell us a lot.
The "random / can't reproduce" detail is actually the important clue. A 1×1 image in the HTML and in the Media Library grid points at the stored attachment metadata (
_wp_attachment_metadata), not the file itself — which lines up with the file opening fine in a new tab. The grid doesn't go through any<picture>rewriting, so if it also shows 1px, the bad dimensions are already saved in the DB. That reconciles "random": the corruption happens at upload time, intermittently. Once an attachment is written with bad dimensions it stays bad, but re-uploading creates a fresh attachment that usually processes cleanly — which is why the same image "worked the second time."One check that localizes the bug. For a known-bad attachment, could you dump its stored metadata?
(or view it via Query Monitor). Two outcomes:
sizes[...]['width']is literally1→ the dimensions were corrupted when the metadata was generated (upload time).<picture>rendering instead.Why literally
1is interesting. Missing or zero dimensions usually render as0or get omitted — a literal1is a narrower fingerprint. It tends to come from a degenerate image resource (e.g. a failed decode falling back to a 1×1) or fromgetimagesize()/ the image editor reading a file that wasn't fully flushed yet and returning just the header dimensions. That last one is inherently intermittent and is much more likely on hosts using object storage / CDN offload (e.g. S3), NFS/network filesystems, or aggressive opcache/stat caching — the original file is read for sub-size generation before it has finished being written, then finishes a moment later (which is why it looks fine afterwards).So a few questions that would help:
memory_limit, and does it correlate with large uploads or batch uploads (several at once)?Happy to help dig further once we see whether the stored width is
1or correct — that splits the problem cleanly.ligne13 commentedon Jun 16, 2026
Hi @MarcinDudekDev ,
sorry for the delay.
I ran
wp post meta get 96904 _wp_attachment_metadataand here is the result:array (
'dominant_color' => '757863',
'has_transparency' => false,
'sources' =>
array (
'image/webp' =>
array (
'file' => 'Fondation-Royaumont-Olivier-Ouadah-cloitre-269-png.webp',
'filesize' => 595090,
),
),
)
There is no sizes key.
The site is not using any S3 / CDN or remote storage plugin.
PHP memory limit is set to 512M.
Thanks for the help.
adamsilverstein commentedon Jun 19, 2026
Thanks for the additional data. It looks like the uploaded image isn't available when core tries to read the file size and the plugs aren't careful about the empty returned value. I'll work on a PR to guard against that.
This indicates some sort of race condition where the upload is happening while the server is not able to read the file size after the upload in
wp_getimagesize, perhaps the disk write hasn't completed. If we can't guard against that, we can at least abort when we see it so you don't get an image showing up at 1x1.adamsilverstein commentedon Aug 28, 2026
This will hopefully be fixed by some recent fixes in clinet-side media landing in 7.1.1 for a related issue with image sizes metadata. Once this ships we can re-test to see if the bug persists.