How to Regenerate Thumbnails in WordPress

WordPress creates image sizes once, at upload — so any change to sizes leaves your existing images behind. Regenerating rebuilds every size from the original. On small sites a plugin does it from the dashboard; on anything with thousands of images, wp media regenerate over WP-CLI is faster and does not time out.

When you need it

• You changed thumbnail, medium or large in Settings › Media.
• You switched theme, and the new one registers different sizes — see WordPress image sizes.
• You added a size with add_image_size and older images do not offer it, the symptom described in image_size_names_choose.
• You migrated or imported media without its generated sizes.
• You resized originals outside WordPress, as in how to resize images.

If none of these happened, regenerating does nothing useful and costs CPU and disk. In particular, it does not fix images that are blurry because the upload itself was too small: WordPress never enlarges, so a 600-pixel original produces the same soft result however many times you rebuild its sizes.

Before you start

1. Back up wp-content/uploads. Regeneration overwrites and can delete files — see WordPress backup plugins.
2. Check free disk space. A new size adds one file per image.
3. Keep the originals. If an optimizer overwrote them with compressed versions, regeneration compresses the already-compressed file again; restore originals first if the plugin kept backups.

Method 1: WP-CLI

# All images, all sizes
wp media regenerate --yes

# Only missing sizes: fastest after adding a new size
wp media regenerate --only-missing --yes

# One size
wp media regenerate --image_size=large --yes

# Keep files of sizes that are no longer registered
wp media regenerate --skip-delete --yes

Run it from the WordPress root. On large libraries, run it inside screen or tmux so a dropped SSH connection does not stop it. --only-missing is the right default when you have just added a size: it skips everything already present. More commands are in the WP-CLI reference.

You can also pass attachment IDs to regenerate only specific images:

wp media regenerate 1234 1235 --yes

How long it takes

Each image is resized once per registered size, so time scales with images × sizes. As a rough guide on shared hosting, expect a few images per second; a 10,000-image library with fifteen sizes can take an hour or more. Practical ways to shorten it:

• regenerate only the size that changed with --image_size;
• use --only-missing after adding a size;
• remove sizes nobody uses before regenerating, so they are not rebuilt;
• run it overnight, when PHP workers are not needed by visitors.

Method 2: a plugin

Without shell access, install a thumbnail-regeneration plugin, run it from Tools, and remove it afterwards — it has no job once the work is done. Choose one that:

• processes images in batches through AJAX, so the request does not time out;
• can regenerate only missing sizes;
• lets you choose whether unregistered sizes are deleted;
• can regenerate a single image from the media library.

On shared hosting, run it during low-traffic hours; each image means several resize operations.

WooCommerce

WooCommerce regenerates its product sizes in the background when you change them in the Customiser. On large catalogues that background process can stall; WooCommerce → Status → Tools → Regenerate shop thumbnails queues a fresh run (the button is disabled while one is still marked as running). For very large stores, WP-CLI is more reliable — pass all three WooCommerce sizes:

wp media regenerate --image_size=woocommerce_thumbnail --image_size=woocommerce_single --image_size=woocommerce_gallery_thumbnail --yes

Size choices themselves are in WooCommerce product image size.

Regenerating a single image

When one image looks wrong — a bad crop on a featured image, or a file replaced over FTP — regenerating everything is overkill. Pass its attachment ID to WP-CLI as shown above, or use the single-image action most regeneration plugins add to the media library. If the crop is still wrong after regenerating, the cause is the size's crop setting rather than the files, which is covered in add_image_size.

Deleting old sizes safely

Switching theme often leaves gigabytes of sizes no template uses. WP-CLI deletes unregistered sizes by default, which is what frees the space — and what breaks any post that hard-coded the URL of one of those files in its content. Search the database for -300x200. style filenames of retired sizes before deleting, or pass --skip-delete and clean up later with --delete-unknown, which removes only files of sizes that are no longer registered. A broader clean-up is in deleting unused images.

After regenerating

New files are uncompressed. If an optimizer plugin compresses on upload, run its bulk optimisation afterwards so the regenerated sizes are compressed too — in Imagify, select the images in Media → Library (list view) and use the Optimize Missing Sizes bulk action. Then purge the page cache and any CDN, or visitors keep receiving old URLs — see how to clear the WordPress cache.

Common mistakes

• Regenerating from compressed originals, compounding lossy compression — see lossy vs lossless compression.
• Running a dashboard plugin on 20,000 images on shared hosting and hitting time limits halfway.
• Deleting retired sizes that posts still reference by URL.
• Forgetting the CDN, which keeps serving the old files.

Verify

1. Open an older image in the media library and confirm its sizes list includes the new dimensions.
2. Check the uploads folder for the new size's suffix on an older image, such as -600x400.jpg.
3. View a page that uses the size and confirm the src points to the new file.