Upload one image to WordPress and the uploads directory gains many files. Core, the theme, WooCommerce and plugins may each register their own dimensions and crops.
Some derivatives are redundant. Others power responsive images, product grids, galleries, admin screens or social presentation. Deleting them by filename pattern can reduce disk usage and quietly break the site.
Treat image sizes as an inventory problem before treating them as clutter.
Understand why WordPress creates derivatives
WordPress generates registered sub-sizes when an image is uploaded. Common core sizes include thumbnail, medium, medium-large and large. Themes and plugins can add more.
Each size may specify:
- width;
- height;
- hard crop or proportional resize;
- public name;
- context where it is used.
Modern WordPress may also scale very large originals. Optimisation plugins can add WebP or AVIF variants, multiplying the files further.
List registered image sizes
Where WP-CLI supports it:
wp media image-sizeIn a controlled WordPress diagnostic, PHP can report registered sub-sizes:
$sizes = wp_get_registered_image_subsizes();
foreach ( $sizes as $name => $details ) {
error_log( $name . ': ' . wp_json_encode( $details ) );
}Do not place this on a public template. Use an authorised temporary diagnostic and protect logs.
Record which component registered each non-core size. The name sometimes reveals it, but confirm in theme/plugin code or documentation.
Count files without assuming every suffix is a WordPress size
Image filenames can naturally end in dimensions. Optimisation tools may use their own naming.
Use file counts as orientation, then connect derivatives to attachment metadata. WordPress stores generated file information in _wp_attachment_metadata.
Do not delete every file matching -300x300. That dimension may be the live catalogue thumbnail.
Map sizes to real templates
Inspect representative pages:
- homepage;
- service cards;
- blog archive;
- article;
- gallery;
- WooCommerce category;
- product;
- related products;
- account/admin views where relevant.
For every image, record the URL selected at common viewports. A size not selected in one desktop session may still serve mobile or a high-density display.
Search theme and plugin code for named size requests such as:
the_post_thumbnail( 'card-landscape' );Also check builder settings and REST/API consumers.
Responsive srcset can use intermediate sizes automatically
Even when a template requests large, WordPress may include several registered candidates in srcset. Removing intermediate files can force mobile visitors to download a larger source.
Before disabling a size, inspect:
- generated
srcset; sizes;currentSrcat target viewports;- intrinsic and rendered dimensions;
- device pixel ratio.
Disk savings can become a bandwidth regression if the remaining candidates are poorly spaced.
WooCommerce image sizes have commercial roles
WooCommerce uses images in:
- catalogue cards;
- single-product gallery;
- gallery thumbnails;
- widgets;
- related products;
- variation presentation.
The active theme can declare WooCommerce dimensions. Builders may add alternatives.
Do not remove a size because it is absent from a blog page. Test the full product journey, including mobile and zoom.
Cropped and uncropped sizes are not interchangeable
Two sizes with similar width may serve different compositions. A square hard crop can keep card rows aligned; a proportional image preserves the full photograph.
If you consolidate them, check:
- subject framing;
- product visibility;
- layout consistency;
- intrinsic dimensions;
- object-fit behaviour.
CSS cropping through object-fit can sometimes replace a physical crop, but it still downloads the source dimensions and changes focal-point behaviour.
Old sizes remain after theme changes
Changing theme or plugins does not normally remove derivatives created previously. The uploads directory can contain files no longer registered.
That makes them candidates for cleanup, but first check:
- hard-coded URLs in content or CSS;
- cached HTML;
- external feeds;
- email templates;
- social previews;
- previous builder content;
- headless/API consumers, if any.
In this project, unsupported headless platforms are not an editorial service target, but an existing site can still have external consumers that must not be broken.
Disabling generation affects future uploads only
Removing a registered size prevents new derivatives. Existing files remain. Conversely, deleting existing files while leaving the size registered means new uploads recreate them.
Plan both sides:
- decide the required future set;
- change registration;
- test new upload metadata;
- map existing derivatives;
- remove only proven-unused files;
- verify rollback.
Use filters carefully
WordPress allows control of generated sizes:
add_filter( 'intermediate_image_sizes_advanced', function ( $sizes ) {
unset( $sizes['unused-custom-size'] );
return $sizes;
} );Use the exact registered key and place code in a maintained custom plugin or child theme. Do not paste it into production before confirming no active template needs the size.
Core, theme or plugin updates may change registration, so document the decision.
Estimate savings before deleting
For a sample of recent uploads, calculate:
- number of derivatives;
- total bytes per registered size;
- WebP/AVIF multiplication;
- frequency of uploads;
- backup/storage cost;
- visitor use.
A tiny rarely generated thumbnail may not justify the risk. One unnecessary 2000-pixel crop across thousands of images may.
Back up both files and attachment metadata
A filesystem backup alone may not restore correct WordPress metadata. A database backup alone does not restore deleted images.
Before cleanup:
- back up uploads;
- back up database;
- record active size registry;
- test restoration of a representative attachment.
Keep the backup outside the directory being cleaned.
Regeneration needs a bounded plan
After changing sizes, regenerate only where needed. Large libraries can consume CPU, disk and PHP workers.
Test:
- one image type;
- one product;
- crop result;
- filenames;
- metadata;
- disk growth;
- page delivery.
Run larger work in controlled batches and monitor errors. Do not allow regeneration to overlap peak traffic or backups.
Verify after cleanup
Check:
- no 404 image requests;
- correct
srcset; - mobile and high-density selection;
- product gallery and zoom;
- blog/card crops;
- WordPress editor previews;
- CDN cache;
- backup size and restore.
Monitor 404 logs for old derivative URLs after deployment.
Evidence for a media-size assessment
Provide the registered size list, active theme/plugins, sample attachment metadata, storage concern and representative page URLs. No passwords are needed for the first review.
If WordPress generates too many image sizes, we can map registered derivatives to real layouts, remove proven redundancy and protect responsive delivery. The result should reduce storage or processing without trading it for larger mobile downloads or broken product imagery.