WordPress Thumbnails Not Generating: Causes and the Fix

You upload an image in WordPress and the full-size file lands in the Media Library just fine - but the thumbnail, medium, and featured-image sizes never show up. Product grids look broken, blog cards show a grey box, and re-uploading the same file doesn't help. Here's what's actually going on and how to fix it without guessing.

Symptom: what you're actually seeing

A few common variations of this bug, all with the same root cause:

• The featured image shows in the editor but not on the front end.
• Only the original full-size image exists in /wp-content/uploads/; the -150x150, -300x200 etc. files are missing.
• WooCommerce product thumbnails are blank even though the main product photo works.
• Uploads that worked last month suddenly stop generating sizes.

Cause 1: The image processing library is missing or broken

WordPress doesn't resize images itself - it hands the job to either the Imagick PHP extension or, as a fallback, GD. If neither is installed, or Imagick is installed but its underlying ImageMagick binary is missing or too old, WordPress silently fails to create the extra sizes. It doesn't throw a visible error on the front end; it just skips the step.

Check which library your account is actually using. In cPanel, go to Select PHP Version → Extensions and confirm imagick and gd are both ticked. On a VPS, check from SSH:

php -m | grep -i -E 'imagick|gd'
php -r "var_dump(extension_loaded('imagick'), extension_loaded('gd'));"

If both come back empty, that's your answer - install one of them. On a cPanel shared account, ticking the extension in MultiPHP Extensions is usually enough. On a VPS running PHP-FPM, you'll need to install the package and restart PHP-FPM:

sudo apt install php8.2-imagick
sudo systemctl restart php8.2-fpm

Cause 2: PHP is running out of memory or time mid-resize

Generating five or six image sizes from one large upload is memory-hungry, especially for high-resolution photos straight off a phone camera (4000px+ wide). If memory_limit or max_execution_time is too low, PHP dies partway through - the original saves, but the resize loop never finishes.

Check your PHP error log for lines like Allowed memory size of X bytes exhausted right after an upload. In cPanel, this is under Metrics → Errors, or via WP-CLI:

wp config get WP_DEBUG_LOG
tail -50 wp-content/debug.log

Raise the limit in wp-config.php (add above the /* That's all */ line):

define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M');

If PHP-FPM has its own pool-level limit that's lower than what wp-config requests, the wp-config value gets capped. Check /etc/php/8.2/fpm/php.ini or the MultiPHP INI Editor for memory_limit and bump it there too - WordPress can't override a hard PHP-level ceiling from inside the app.

Cause 3: A corrupted original file or bad permissions

If only certain images fail while others upload fine, the file itself is often the problem - a corrupted EXIF block, an unusual color profile (CMYK instead of RGB), or a file that isn't really the type its extension claims. Try opening the original in an image editor and re-saving it as a plain RGB JPEG or PNG, then re-upload.

Permissions cause a quieter version of the same failure: if wp-content/uploads/ or a dated subfolder inside it isn't writable by the web server user, WordPress can save the original (sometimes to a fallback location) but can't write the resized copies. Correct ownership and permissions from SSH:

find wp-content/uploads/ -type d -exec chmod 755 {} \;
find wp-content/uploads/ -type f -exec chmod 644 {} \;

On shared cPanel hosting, permissions usually stay correct unless a migration or backup restore reset them - check File Manager → uploads folder → Permissions if this started right after a site move.

It's worth ruling out third-party plugins too. Image optimization tools, WebP converters, and some page builders hook into the upload process and occasionally swallow errors instead of surfacing them. Deactivate all plugins except WooCommerce (if you run it) and re-upload a test image - if sizes generate cleanly, reactivate plugins one at a time until the culprit shows up.

Cause 4: Old files are cached, so the fix doesn't look like it worked

Once you fix the underlying cause, new uploads generate sizes correctly - but images uploaded while the bug was active stay broken, because the missing thumbnail files genuinely don't exist on disk. No amount of cache clearing fixes a file that was never created. You have to regenerate them.

How to regenerate missing thumbnails

Once Imagick/GD, memory, and permissions are all fixed, rebuild every size for existing uploads. Two options:

Option A: Regenerate Thumbnails plugin

1. Install and activate Regenerate Thumbnails from the plugin repository.
2. Go to Tools → Regenerate Thumbnails.
3. Click Regenerate All Thumbnails and let it run - large libraries can take a while, so don't close the tab.

Option B: WP-CLI (faster for large media libraries)

wp media regenerate --yes

For a huge library, throttle it so you don't spike server load:

wp media regenerate --yes --image_size=thumbnail
wp media regenerate --yes --image_size=medium

Prevention

• Keep Imagick enabled rather than relying on GD alone - it handles large images and more formats more reliably.
• Set WP_MEMORY_LIMIT to at least 256M on any site with a media-heavy theme or WooCommerce.
• Resize oversized camera photos before upload, or install an image optimization plugin that compresses on upload.
• After any migration or backup restore, spot-check a recent product or post image before assuming the move went cleanly.