When you upload a single image to WordPress, you are not uploading one file. You are initiating the creation of anywhere from three to ten files, depending on how many image sizes your theme and plugins have registered. The original is stored. Then WordPress immediately generates a resized copy for each registered image size: a thumbnail, a medium size, a large size, and whatever custom sizes your theme has defined. Each WooCommerce installation adds several more. Page builders sometimes add their own. The original file you uploaded might be one of eight files now sitting in your uploads directory because of that single upload action.
Most WordPress site owners understand this in a vague way but have never calculated what it actually means for their storage usage over time. The numbers are striking once you see them clearly, and the downstream effects of thumbnail multiplication, from storage consumption to maintenance task duration to the cost of regeneration when something changes, add up to a significant hidden operational cost that most site owners absorb without realizing it.
This guide breaks down the thumbnail multiplication problem quantitatively, explains what happens during regeneration and why it is painful at scale, and describes the infrastructure approach that removes the majority of this cost from your hosting server permanently.
How WordPress thumbnail multiplication actually works
When you upload an image to WordPress, the upload process triggers a series of image generation steps that most users never see. WordPress reads the uploaded file, determines its dimensions, and generates a resized copy for every image size that has been registered in the system. Each generated copy is saved as a separate file in your uploads directory with a filename that appends the dimensions, for example image-name-150×150.jpg for a 150-pixel thumbnail.
The number of sizes registered depends on your theme and plugins. WordPress itself registers three default sizes: thumbnail (150×150), medium (300×300), and large (1024×768). Most themes register additional sizes suited to their layout: a featured image size, a blog listing size, a widget size. WooCommerce registers its own product image sizes. Page builders like Elementor or Divi register yet more. A fully featured WordPress installation with WooCommerce and a premium theme typically has six to ten registered image sizes, meaning six to ten files generated per upload.
A standard WordPress + WooCommerce + premium theme setup with 8 registered image sizes:
1 upload = 1 original + 8 generated sizes = 9 files per image
100 product images = 900 files
1,000 product images = 9,000 files
5,000 images across site = 45,000 files
10,000 images across site = 90,000 files
Most shared hosting inodes limits: 100,000–250,000 total files. A site with 10,000 source images has already consumed a significant portion of its inode allocation purely from thumbnail generation.
The storage overhead: what thumbnail generation actually costs in disk space
The storage cost of thumbnail generation is not simply the number of extra files multiplied by the original file size. Smaller thumbnail sizes are dramatically smaller than the original. But the total overhead is still substantial, and it compounds with library size in ways that are easy to underestimate.
That last row is worth sitting with. For every 800KB image you upload, WordPress generates approximately 793KB of additional thumbnail files. Your total storage consumption per image is nearly double the original file size just from thumbnail generation. At scale, this means that half of your uploads directory consists of thumbnail variants that exist solely to serve different display contexts across your site.
What thumbnail regeneration actually does to your server
Thumbnail regeneration is the process of rebuilding all thumbnail variants for every image in your media library. You need to do this when you change themes, when you adjust registered image sizes, when you add a new plugin that requires its own image sizes, or when you switch image compression settings. It is a routine WordPress maintenance task that every site owner eventually encounters.
What makes it painful at scale is what the process actually requires. For each image in your library, the server must read the original file from disk, load it into memory, resize it to each registered dimension, apply compression, and write the result as a new file. This is CPU-intensive, memory-intensive, and disk I/O intensive simultaneously. On a shared hosting server that is also handling PHP requests and database queries for live visitors, a regeneration job is a significant competing load.
Image resizing is computationally expensive. PHP’s GD or Imagick library processes each image sequentially, performing full decode-resize-encode cycles. On a library of 10,000 images generating 8 sizes each, this is 80,000 image processing operations. On shared hosting where CPU is throttled and shared across dozens of sites, this process can push CPU usage to limits that trigger throttling or temporary suspension of the process.
Typical regeneration speeds on shared hosting run at 100 to 500 images per minute depending on server performance and image complexity. A library of 5,000 images takes 10 to 50 minutes of active processing time. A library of 20,000 images can take 40 minutes to over 3 hours. This entire window, the site is running under elevated server load with an elevated risk of timeout errors that require the process to be restarted.
Regeneration reads every original file from disk and writes multiple new files per original. On a 10,000-image library, this involves reading approximately 8GB of original files and writing approximately 8GB of new thumbnail files. The disk I/O from this operation is visible in hosting monitoring tools and can slow other disk-dependent operations on the same server during the regeneration window.
Most site owners encounter regeneration more often than they realize. Switching themes triggers it. Installing a new page builder plugin triggers it. Changing WooCommerce image settings triggers it. Installing an image optimization plugin that adjusts sizes triggers it. On an actively maintained WordPress site, full or partial regeneration runs are a realistic once or twice per year occurrence, and each run is more painful than the last as the library grows.
How FTP offloading structurally changes the thumbnail problem
Offloading media to an external FTP server does not eliminate thumbnail generation. WordPress still generates thumbnails during upload, because thumbnails are generated on your hosting server by PHP and then transferred to the FTP destination along with the original. What offloading does eliminate is the long-term storage burden of thumbnails on your hosting server.
When automatic local file deletion is enabled after transfer, every image and all its thumbnail variants leave your hosting server filesystem once transferred to FTP. Your hosting server’s uploads directory stays nearly empty regardless of how many images your site has published. The inode consumption, the storage warnings, and the ever-growing backup size are all eliminated because the files are not on your hosting server.
When you need to regenerate thumbnails after a theme change or image size adjustment, the regeneration process still runs on your hosting server using the original files. This is one reason it is worth considering whether to keep local copies of original files on your hosting server while offloading only the thumbnails, at least temporarily. Some FTP media plugin configurations support this approach, keeping originals local for regeneration while offloading thumbnails to reduce the storage footprint. After regeneration is complete, the new thumbnail versions are synced to FTP and local copies are removed.
Reducing registered image sizes: the other side of the problem
Offloading media to FTP addresses where thumbnails are stored. But a complementary approach is reducing how many thumbnail sizes are generated in the first place. Many WordPress installations register image sizes that are never actually used in the site’s output because they were registered by a plugin or theme that was later deactivated or replaced.
You can audit the registered image sizes in your WordPress installation using a plugin like Regenerate Thumbnails Advanced or by inspecting your theme’s functions.php for add_image_size() calls. Sizes registered by deactivated plugins continue to exist in WordPress’s image size registry until explicitly removed, and if you have regenerated thumbnails since those plugins were active, those now-unused sizes are still taking up space on disk.
Install a tool like Regenerate Thumbnails or use WP-CLI’s wp media image-size list command to see all registered sizes. Compare the list against what your current theme and active plugins actually need. Any size not referenced in your current template files or by active plugins is a candidate for removal.
Use the remove_image_size() function in your theme’s functions.php to deregister sizes no longer needed. Then use a plugin like DNUI (Delete Not Used Image Sizes) to remove the physical thumbnail files for deregistered sizes from your uploads directory. This can recover significant disk space on older sites that have accumulated thumbnails for many defunct sizes.
WordPress’s big image threshold (introduced in WP 5.3) automatically scales down very large uploaded images to a maximum of 2560px on the longest edge, keeping the original as a “scaled” version and working from the scaled copy for thumbnail generation. This limits storage waste when photographers or designers upload very high-resolution originals. Setting the threshold to match your site’s largest display size prevents unnecessarily large originals from multiplying into even larger storage footprints across all thumbnail sizes.
The complete picture: combining size reduction with FTP offload
The most effective approach to the thumbnail problem combines two strategies: reducing the number of sizes generated, and offloading the sizes that are generated to external FTP storage. Neither strategy alone is as effective as both together.
Reducing registered image sizes reduces the per-upload file count and the per-upload storage overhead. It also speeds up regeneration operations when they are needed, because fewer files need to be processed. Offloading to FTP removes the files that are generated from your hosting server’s filesystem, eliminating the storage warnings, inode pressure, and backup size inflation that thumbnail accumulation causes over time.
According to WordPress developer documentation on image sizes, each theme should register only the image sizes it actually uses in its templates. The documentation explicitly notes that registering additional image sizes increases storage requirements and media upload time. This is the official guidance, but plugin authors and theme developers frequently register extra sizes as a precaution or for optional features, leaving sites with registered sizes that serve no purpose in the current configuration.
A site that has audited and cleaned up its registered image sizes, combined with a media offload workflow that moves generated files to FTP after processing, has addressed the thumbnail problem at both the generation layer and the storage layer. The result is a hosting server that processes image uploads quickly, keeps no long-term storage burden from those uploads, and never faces a storage warning from thumbnail accumulation regardless of how actively the site publishes new content. WP FTP Media’s thumbnail-aware WordPress storage offload is the infrastructure layer that makes the second part of this strategy operational.
Stop storing thumbnail multiplication on the server that least needs it
WP FTP Media transfers every generated thumbnail and image variant to your FTP server automatically, deletes local copies to free hosting disk space and inodes, and serves all sizes via CDN, keeping your hosting filesystem clean regardless of how many images you publish.
Wow, this really opened my eyes. I run a volunteer site with over 5k images and never realized how much space those auto generated thumbnails were eating up
Oh wow, this guide just saved me from a huge headache! i run a small mom blog with about 5,000 photos (yes, my kids are that cute), and I had no idea WordPress was secretly creating like 5 copies of every single one. That explains why my hosting storage keeps filling up so fast!
Hey, this saved me so much time!