WordPress thumbnail generation is a pipeline: it stores the original, decodes it with GD or Imagick, creates registered sizes and writes attachment metadata. A failure at any step can leave the original available but the derivatives missing.
Start with one controlled upload
Test a modest JPEG and one representative large image. If the small file works but the large one fails, memory or pixel dimensions are more likely than a global filesystem problem.
Confirm the image-processing runtime
Check which library is active, supported formats and PHP memory. File size alone is misleading: a compressed image can require far more memory once decoded.
Inspect attachment metadata before regenerating
Missing size records, processing errors or inconsistent metadata can identify whether generation stopped before or after files were written.
Check the uploads filesystem
WordPress needs to create files in the target year/month directory. If writes fail, follow the ownership and permission checks rather than opening permissions broadly.
Separate generation failure from Media Library UI failure
If derivatives exist on disk but the grid is blank, use the Media Library grid diagnostic. These are different failure paths.
Regenerate only after fixing the cause
Once processing, memory and filesystem health are stable, regenerate the affected attachments and confirm that new uploads create every registered size. Theme pages should then serve the intended derivatives rather than oversized originals.
WP REPAIR INCIDENT STANDARD
Reconstruct the incident before fixing it
Testing one small JPEG and one realistic large image separates format and resource issues.
- 1
Confirm the original file exists and is readable.
- 2
Inspect attachment metadata for missing sizes or an error.
- 3
Check active GD/Imagick support, memory and pixel dimensions.
- 4
Read PHP logs during a controlled upload or regeneration.
What must be verified
- New uploads generate every registered size.
- Affected attachments can be regenerated without errors.
- Theme pages serve the intended derivatives rather than oversized originals.
Official technical sources
Continue the diagnosis
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
If the original uploaded image is fine, why would its thumbnails still fail to generate?+
Because the original passes through several separate steps — the GD or Imagick library, resizing for each registered size, and writing attachment metadata — and a failure at any one of those steps leaves a perfectly usable original with missing derivatives.
Does a large file size always mean the image will run out of memory during processing?+
Not necessarily — pixel dimensions matter more than file size. A visually small but high-resolution image can consume far more processing memory than its file size suggests, which is why testing both a small JPEG and a realistic large image separately helps isolate the cause.
Is repeatedly regenerating thumbnails a good way to troubleshoot this?+
No, especially under constrained disk or memory. Repeated regeneration attempts while resources are limited can worsen the underlying condition rather than reveal what's failing — check the image library, memory limits, and PHP logs first.
Can WordPress accept an upload but still fail to create any of its derivative sizes?+
Yes. This can happen if the filesystem write for derivative files fails even though the original was saved successfully — for example due to incorrect uploads ownership or insufficient disk space at generation time.