Why Your WordPress Uploads Folder Is So Large

Your WordPress uploads folder is large because WordPress never stores one file per image. Every upload triggers a fixed set of resized copies alongside the original — seven of them for a typical camera-sized photo, before any theme or plugin adds more. Nothing is corrupted; you’re just seeing the multiplication that happens on every single upload. The fix is to stop generating the sizes you never serve, then regenerate so the old copies get deleted from disk.

Do the arithmetic

Upload one 4000×3000 JPEG and look inside /wp-content/uploads/2026/07/. You won’t find one file. You’ll find these:

• photo.jpg — the original, untouched
• photo-scaled.jpg — a 2560px copy WordPress serves instead of the original
• photo-150x150.jpg — thumbnail
• photo-300x225.jpg — medium
• photo-768x576.jpg — medium_large
• photo-1024x768.jpg — large
• photo-1536x1152.jpg — the 2× medium_large
• photo-2048x1536.jpg — the 2× large

That’s the original plus seven derivatives, from core alone. A 3 MB upload can land as 5–6 MB on disk before a single plugin runs. Now add a theme that registers four sizes of its own and WooCommerce (three more), and one upload becomes fourteen or fifteen files. Multiply by a library of a few thousand images and the folder size stops being a mystery.

If you want the exact number for your own dimensions and registered sizes, the image storage calculator does the multiplication for you.

Why it happens

When you upload, wp_generate_attachment_metadata() calls wp_create_image_subsizes(), which loops over every size returned by get_intermediate_image_sizes() and writes a file for each one the original is large enough to produce. Core registers thumbnail, medium, medium_large, large, plus the 1536x1536 and 2048x2048 retina sizes added in WP 5.3. Any theme or plugin that calls add_image_size() adds to that same loop — permanently, for every future upload.

The -scaled file comes from a separate mechanism: the big_image_size_threshold filter, default 2560px. Anything wider gets a scaled copy that becomes the served “full” image, while the original stays on disk. So a large upload keeps both the giant original and the 2560px version.

You can see exactly what your setup generates for a given image with the image sizes inspector.

How to fix it, in order

1. Measure before you touch anything. Guessing wastes time. From the site root:

du -sh wp-content/uploads
find wp-content/uploads -type f \( -name '*.jpg' -o -name '*.webp' -o -name '*.png' \) | wc -l
du -ah wp-content/uploads | sort -rh | head -20

2. Deregister the sizes you don’t serve. Most themes never output the 1536 and 2048 sizes, and many never use medium_large. Drop them:

// functions.php — stop generating sizes this site never outputs
add_action( 'init', function () {
    remove_image_size( '1536x1536' );
    remove_image_size( '2048x2048' );
} );

// Drop medium_large too, if your theme doesn't use the 768px size
add_filter( 'intermediate_image_sizes_advanced', function ( $sizes ) {
    unset( $sizes['medium_large'] );
    return $sizes;
} );

3. Regenerate to delete the old copies. Deregistering only stops future generation — the files already on disk stay until you regenerate:

wp media regenerate --yes

Recent WP-CLI versions delete files for sizes that are no longer registered as they go. If you’re on the Regenerate Thumbnails plugin instead, tick its “delete unregistered sizes” option — without that box checked, the old files remain.

4. Hunt orphaned files. Switching themes never cleans up the sizes the old theme registered. Deleting posts doesn’t always remove their derivatives either. After step 3, if du -sh is still far above what the calculator predicts, you have orphans — files on disk that no attachment references.

What not to do

Don’t disable scaled images to “save space.” The -scaled file is smaller than your original. Turning off big_image_size_threshold deletes nothing — it just makes WordPress serve the full multi-megabyte original to every visitor. That’s a bandwidth and quality decision, not a storage cleanup, and it usually makes page weight worse. The disable-scaled-images tool explains when it’s actually the right call; shrinking your uploads folder isn’t one of them.

Don’t delete files straight from uploads over SFTP. Each attachment’s subsize list lives in its _wp_attachment_metadata. Deleting files by hand leaves broken references, and regeneration can’t rebuild a size if you’ve removed the original it’s derived from. Delete the original and that image is gone for good.

Don’t set thumbnail/medium/large to 0 in Settings → Media expecting the folder to shrink. Zeroing a size stops future generation but touches nothing already on disk, and the UI can’t reach medium_large, 1536, 2048, or any theme/plugin size — those aren’t there.

Don’t blame the database. A heavy uploads folder is image files, essentially never the DB. Optimizing tables won’t move the number.

Still stuck?

If the folder is still larger than expected after regenerating, run your real image dimensions and registered sizes through the storage calculator and compare its figure to du -sh wp-content/uploads. A big gap means orphaned files from an old theme or deleted posts — not core, and not something more regenerating will fix. A small gap means the math is simply what it is: seven-plus files per upload, working exactly as designed.