WordPress keeps crashing when you upload lots of images: what’s really happening (and what to change)

I see this a lot on WooCommerce stores: you try to upload a batch of product photos, the browser spins, and then you get a white screen, a 500 error, or WordPress quietly dumps you back into the Media Library with half your images missing. People describe it as “WordPress crashing”, but what’s usually happening is much simpler: the server runs out of breathing room while WordPress is trying to process too many images at once.

What “crashing” usually means during a bulk upload

When you upload an image, WordPress doesn’t just save the original file. It also generates resized copies (“thumbnails”) for different parts of the site. WooCommerce adds its own set of sizes for product images too. That’s great for performance on the front end, but it means an upload isn’t a single job.

A common pattern is:

• You upload 30 images in one go.
• Your theme + WordPress + WooCommerce have, say, 6 registered image sizes.
• That becomes 30 × 6 = 180 resize operations, plus metadata, plus file I/O.

Now add any extra plugins that hook into uploads (optimisers, security scanners, gallery tools), and it’s very easy to hit a limit: PHP memory, maximum execution time, server CPU, disk quota, or request size.

The giveaway error, when you can see it, is often PHP’s “Allowed memory size exhausted”. WordPress explicitly calls out increasing memory (or asking your host to do it) when you hit that error. See the WordPress common errors page for background: WordPress common errors.

Why image sizes multiply the work (especially on WooCommerce)

WordPress can create several image sizes per upload, and WooCommerce uses separate sizes for catalogue, thumbnails and product images, which increases processing and storage. WooCommerce’s own docs talk through adding product images and galleries, and (importantly) that you don’t need absurdly large originals for a normal storefront: Adding product images and galleries.

Two practical consequences:

• Simultaneous uploads magnify load. Your browser can upload multiple files at once, so the server is trying to handle several image-processing jobs concurrently.
• Big originals are expensive. Huge camera images take longer and use more memory to decode and resize. That’s often where “it works for a few images but not a batch” comes from.

Step 1: check what your server will actually allow

Before you change anything, grab the basics so you’re not guessing.

1) Use Site Health to record key limits

1. Go to Tools → Site Health.
2. Open the Info tab.
3. Look under Server.

Make a note of:

• PHP memory limit
• Max upload size (this is usually tied to upload_max_filesize)
• Max post size (tied to post_max_size)
• PHP version
• Any obvious disk space / quota warnings

If you want the more developer-y view of what WordPress exposes via Site Health, the underlying class is documented here: WP_Debug_Data.

2) Make sure request size limits aren’t the silent blocker

Two PHP settings matter a lot for uploads:

• upload_max_filesize: the maximum size of a single uploaded file
• post_max_size: the maximum size of the entire HTTP request (so it must be at least as big as upload_max_filesize)

That relationship (and other PHP upload considerations) is covered in WordPress’s PHP performance guidance: PHP performance.

Even if memory is fine, you can still see “random” failures if you try to upload multiple medium-sized images in one request and hit post_max_size.

Step 2: fix memory limits the right way (host first, then WordPress)

WordPress has its own memory constants, but they only request memory from PHP. They cannot override whatever your host has enforced at the server level. This is where people waste time: they add lines to wp-config.php, nothing changes, and they assume WordPress is broken.

WordPress documents default memory behaviour (including the common defaults of 40 MB for single-site and 64 MB for Multisite, and a higher admin-side limit via WP_MAX_MEMORY_LIMIT) in the wp-config reference: wp-config.php.

1) Ask the host (or change the plan setting) for a higher PHP memory_limit

If you’re on managed hosting, there’s often a control panel toggle. If not, it’s a support ticket. Tell them you’re hitting memory exhaustion during image processing / thumbnail generation.

Once the server-side limit is raised, then it makes sense to set WordPress’s requested limits.

2) Set WordPress memory constants (if your host allows it)

In wp-config.php, above the “That’s all, stop editing” line, you can add:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Use values your hosting plan supports. If the host caps PHP at (say) 256M, defining 512M won’t magically give it more.

WordPress also has a function specifically aimed at memory-intensive operations (including image manipulation): wp_raise_memory_limit(). That doesn’t replace proper server limits, but it’s part of why image uploads can behave differently to normal page loads.

Step 3: reduce how much work each upload creates

This is the bit most store owners can fix immediately, without waiting on hosting.

1) Don’t upload camera originals if you don’t need them

WooCommerce recommends product images of at least 800 × 800 pixels for good rendering across the main image, catalogue and thumbnail. That guidance is in their product images documentation: Product page and images (Customizer).

That doesn’t mean you can’t upload bigger, but it’s a sensible baseline. In practice, uploading consistently sized images (rather than a mix of huge originals) makes bulk uploads far more reliable and speeds up thumbnail generation.

2) Check how many image sizes you’ve got configured

On WooCommerce sites, you can tweak product image dimensions and cropping in:

Appearance → Customize → WooCommerce → Product Images

If you’ve inherited a site that’s been through a few theme changes, you can end up with lots of extra registered sizes (some used, some not). Every extra size is more processing on upload.

3) Upload smaller batches

If you’re currently selecting 100 images and hitting upload, try 10–20 at a time. It’s not glamorous, but it avoids spikes in CPU/memory and it makes failures easier to isolate.

As a rule of thumb: if 10 works and 50 fails, your server isn’t “randomly crashing” — you’re just finding the ceiling.

Step 4: temporarily remove extra processing (plugin conflicts are real)

Anything that hooks into uploads can turn an already heavy job into a failing one. Common culprits:

• Image optimisation plugins (especially if they optimise on upload)
• Plugins that generate extra sizes (responsive image sets, retina variants, sliders)
• Security plugins that scan every uploaded file
• Gallery/media management plugins with background processing turned off

The quickest test is boring but effective:

1. Take a backup (or do this on staging if you have one).
2. Disable the plugins most likely to touch uploads.
3. Try uploading the same batch again.

If the “wordpress media upload crashing” problem disappears, re-enable plugins one by one until you find the trigger. Then you can decide whether it needs configuration, a higher server limit, or replacing.

Step 5: turn on logging so you can see the real error (safely)

When an upload fails, WordPress often can’t show you a friendly message, because the failure is happening at PHP/server level. Logging is how you stop guessing.

WordPress’s debugging guide explains how to enable WP_DEBUG and log to a file, and it explicitly notes you should not expose logs publicly on production: Debugging in WordPress.

Temporarily, you can set this in wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Then reproduce the failed upload and check the log. If you see:

• Allowed memory size exhausted → memory limit issue (PHP/WordPress)
• Maximum execution time exceeded → timeouts while resizing
• Disk quota exceeded / No space left on device → storage problem

Once you’ve got what you need, turn debugging back off.

Step 6: only regenerate thumbnails after you’ve fixed the underlying limits

A common trap: someone changes image dimensions (or switches theme), then immediately regenerates thumbnails across the entire library, and the site falls over. Regeneration is basically “bulk upload processing, but for everything you’ve ever uploaded”.

If you need to regenerate thumbnails:

1. Fix memory/timeouts first.
2. Do it in smaller batches where possible.
3. Keep an eye on disk space: new sizes mean more files.

If you’re changing sizes on a live shop, take a backup first. There’s no clever shortcut around that.

If you just need to get the images in without the browser falling over

Sometimes the immediate need is simple: you’ve got a pile of product images to get into the Media Library today, and the standard uploader is timing out or choking on batch uploads.

That’s exactly why I built my bulk uploader after dealing with this pattern on real stores. If you want a more reliable workflow for pushing lots of files into WordPress media, have a look at my bulk media uploader plugin for large image batches. It’s a lightweight fix for a problem that shouldn’t take your whole site down.

Conclusion: it’s rarely “random” — it’s load and limits colliding

If WordPress media upload keeps crashing when you upload lots of images, it’s usually not mysterious corruption. It’s the combination of (a) multiple registered thumbnail sizes, (b) several simultaneous uploads, and (c) server limits like memory, timeouts, request size, or disk space.

Start with the practical stuff: upload smaller batches, resize images sensibly (WooCommerce’s 800 × 800 guidance is a good baseline), and confirm your server limits in Site Health. If you still hit failures, raise the PHP memory limit with your host, then set WordPress memory constants, and use logging to confirm the real error.

If you want the easy option for getting big batches into the Media Library without the standard uploader becoming a bottleneck, my Bulk Media Uploader is there. And if you get stuck and want another pair of eyes on it, drop me a line via Contact Us.