WordPress thumbnail sizes: remove the ones you never use

Upload a single product photo to your media library, then look at your uploads folder over FTP: WordPress has created 6, 8, sometimes 10 copies of it. On a WooCommerce store with 2,000 products, this mechanism silently multiplies your files, bloats your backups and stretches every migration. The most annoying part: a good share of those copies are never displayed anywhere.

I went through this exercise recently on a client’s store, a wholesaler with a large catalog. Here is the full method: identify what’s actually used, remove the rest, regenerate cleanly.

Where do all these copies come from?

Three sources add up:

WordPress core generates thumbnail (150×150), medium (300×300), medium_large (768), large (1024) by default, and since WordPress 5.3, two extra sizes at 1536 and 2048 pixels for high-density screens.

WooCommerce and your theme add their own: the gallery thumbnail (100×100), the single product image (600×600 by default), the product grid size, and sometimes formats inherited from old themes that haven’t been used in years.

Plugins, finally: an SEO plugin may register social sharing formats (1200×675, 1200×900), a slider its own dimensions, and so on.

Every registered size = one file created for every uploaded image, forever, whether that size is displayed somewhere or not.

The -scaled case: duplicates nobody talks about

Since WordPress 5.3, any image wider than 2,560 pixels gets duplicated into a -scaled version, which becomes the “full size” image served on the front end. Two little-known consequences: thumbnails are sometimes generated from the original AND from the scaled version, hence duplicates on disk, and above all, when you delete a media item, the -scaled files are not always cleaned up. The result: orphan files piling up, invisible from the media library.

The 2,560 pixel threshold can be changed, and on a store where no image is ever displayed beyond 1,200 pixels, lowering it is plain common sense:

// Lower the -scaled creation threshold (2560px by default)
add_filter( 'big_image_size_threshold', function () { return 1200; } );

Step 1: identify the sizes actually served

Don’t delete anything before measuring. The method I use: scan about ten representative pages (home, categories, tags, product pages) and record the dimensions requested in the src and srcset attributes of image tags. DevTools is enough: Network tab, Images filter, displayed dimensions column.

On my client’s store, the scan verdict was clear-cut: of all the sizes generated, only 5 were actually served (the 150 admin thumbnail, the 300 content fallback, the 462 product grid, the 600 single product image and the 100 gallery thumbnail). The 768, 1024, 1536, 2048 and two inherited formats at 64×64 and 266×266: never served, on any page. Tens of thousands of files for nothing.

To list what your installation registers, one WP-CLI command:

wp eval 'print_r( wp_get_registered_image_subsizes() );'

Step 2: remove the useless sizes

Once you have your list of dead sizes, one filter stops WordPress from generating them:

// Stop generating sizes that are never served
add_filter( 'intermediate_image_sizes_advanced', function ( $sizes ) {
	unset( $sizes['medium_large'] ); // 768, never served
	unset( $sizes['large'] );        // 1024, never served
	unset( $sizes['1536x1536'] );
	unset( $sizes['2048x2048'] );
	return $sizes;
} );

Adapt the list to YOUR scan, not mine: if your theme displays 1024 in its banners, large must stay. That’s the whole point of step 1.

Step 3: regenerate and clean up the existing files

The filter only affects future uploads. For the existing library, you regenerate, which removes the old sizes and only recreates the ones still registered. Backup first, always:

# Back up the uploads folder
tar -czf uploads-backup-$(date +%Y%m%d).tar.gz wp-content/uploads/

# Regenerate: removes old sizes, recreates the registered ones
wp media regenerate --yes

On a large catalog, run the regeneration during off-peak hours: it’s CPU-hungry. And if you don’t have WP-CLI access, the Regenerate Thumbnails plugin does the same job, more slowly.

What you actually gain, honestly

Let’s be precise about the gains, because they’re not where you’d expect. On display speed, the direct impact is modest: the browser only downloads the size listed in the srcset, and unused files sleep on the disk without slowing your pages down. The real gain is elsewhere: an uploads folder two to three times lighter, faster and cheaper backups, migrations that no longer take hours, and a server that stops generating 10 files on every image upload.

The exception that changes everything: if your scan reveals a page serving an ill-fitted size (a product grid displaying 600×600 images in 300 pixel cells is a classic), then you’re touching page weight and LCP directly. That diagnosis is part of my audit method, and image fixes belong to the broader WooCommerce optimization work.

My advice

Do this cleanup when you change themes: that’s when the useful sizes change, when the product grid gets adjusted, and when a full regeneration is needed anyway. It’s exactly what we planned at my wholesaler client’s, alongside their FSE theme rebuild. Two projects, one regeneration.

Curious how many dead sizes are sitting in your uploads folder, and what’s really slowing your store down? Request a free audit: report within 48 hours.