Why WordPress falls over on big image uploads (and what I do about it)

I see the same pattern on WooCommerce sites: a store manager tries to upload a folder of product photos (often straight from a phone or DSLR), the progress spinner hangs, and then WordPress either throws a vague error or the whole admin feels like it’s crashed. The annoying bit is the files often aren’t even that huge individually. The problem is the amount of work WordPress is doing all at once.

What’s actually happening when you upload one image

When you upload an image to WordPress, you’re not just saving a file into wp-content/uploads. WordPress has to process it.

Typically, for each image, WordPress will:

• Decode the original image (turn the compressed JPEG/WebP into an uncompressed bitmap in memory while it works on it).
• Generate multiple resized versions (thumbnails / intermediate sizes).
• Build responsive image metadata (so the theme can output srcset).
• Sometimes create a scaled “big image” version if the upload is very large.

That decode step is the bit that catches people out. A JPEG can be “only” a few MB on disk, but in memory it can balloon while it’s being processed. WordPress even has special logic to try to raise the memory limit for image operations because this is so common. The GD image editor class documentation spells out that it may need more memory than the file size suggests while it’s loading and processing the image (WP_Image_Editor_GD::load()).

Why “upload lots of images” is where things fall apart

One image is usually fine. Thirty images at once is where the wheels come off.

Here’s the simple maths I explain to clients: if you upload 30 images in one go, and your site has (say) 6 registered image sizes that get generated on upload, that’s 30 × 6 = 180 resize jobs. And that’s before you count any “big image” scaling, EXIF rotation, compression plugins, watermarking, CDN offload, or anything else layered on top.

Those resize jobs are CPU-heavy and memory-hungry. If you hit the server with a pile of them at the same time, you can run into:

• PHP memory limits (fatal errors like “Allowed memory size exhausted”).
• Execution timeouts (“Maximum execution time exceeded”).
• Web server request limits (for example HTTP 413 “Request Entity Too Large”).
• Image library errors from GD or ImageMagick when the server is under strain.
• Disk / temporary storage issues (WordPress needs working space while it creates the derivatives).

This is why the search phrase I see people arrive with is basically “wordpress media upload crashing”. They’re not wrong — it feels like a crash — but it’s usually the server protecting itself from a single request that’s become far too heavy.

Step 1: Find out which limit you’re hitting (don’t guess)

If you change random settings without knowing the failure mode, you can waste hours.

1) Check what WordPress thinks your environment is

1. Go to Tools → Site Health → Info.
2. Look for memory limit, upload limits, and anything obviously constrained.

2) Look for the actual error in logs

Ask your host for the PHP error log (and ideally the web server error log too) for the time of the failure. You’re looking for messages like:

• Allowed memory size exhausted
• Maximum execution time exceeded
• HTTP 413 (often Nginx/Apache rejecting the request before WordPress even sees it)
• HTTP 500 with an accompanying PHP fatal error
• Imagick/GD errors

If you’re seeing WordPress’s own message along the lines of “The server cannot process the image…”, that’s usually still an underlying resource issue rather than “WordPress is broken” (WordPress support thread example).

Fix 1: Upload fewer images at a time (yes, it’s boring, but it works)

The quickest way to stop the crashes is to reduce concurrency. If you’re currently dragging 100 images in at once, try 10–20. If it’s still failing, try 5.

This helps in two ways:

• You reduce peak CPU/memory usage on the server.
• If one particular file is problematic, you can find it (rather than the whole batch failing).

Also avoid stacking jobs. If a backup is running, a malware scan is mid-flight, and you start a big media upload, you’re setting yourself up for timeouts.

Fix 2: Resize images before you upload them (it’s the biggest win)

The most practical advice I can give store teams is: don’t upload camera originals unless you genuinely need them.

Product photos usually don’t need to be massive. Your theme displays them at specific maximum dimensions. Anything much bigger than that just increases processing time and memory use for very little real-world benefit.

WordPress has a built-in “big image” threshold. The documented default is 2,560 pixels on the longest side (WordPress client-side media guide). If you upload something larger than that, WordPress may generate a scaled version, which is yet another chunk of processing to do.

My usual approach is:

1. Decide the largest size the site actually needs (based on theme layout and product gallery behaviour).
2. Resize images to that (or a bit above it) before upload.
3. Use sensible formats (JPEG/WebP/AVIF depending on your workflow and compatibility).

If you’re a developer and you want to change the big image threshold, WordPress exposes a filter called big_image_size_threshold. I’m not going to tell you “set it to X” because it depends on the design and image quality expectations, but here’s what the filter looks like in practice:

add_filter( 'big_image_size_threshold', function( $threshold ) {
    // Example only: test thoroughly for product image quality.
    return 1920;
} );

Do this on staging first and check product galleries, zoom features, and any responsive behaviour before you commit.

Fix 3: Make sure the server limits match the job you’re asking it to do

There are two separate categories of limits here:

• Upload limits: whether the server will accept the file.
• Processing limits: whether PHP and the image library can actually create all the resized versions.

Common settings involved are:

• upload_max_filesize (max size per file)
• post_max_size (max size of the entire request; usually needs to be bigger than upload_max_filesize)
• memory_limit (PHP memory per request)
• max_execution_time (how long PHP is allowed to run)

If you’re on Nginx, there may also be client_max_body_size, which can block uploads before PHP sees them.

On managed hosting, you often can’t fix these properly from inside WordPress. You may need to change them in the hosting panel or ask support.

One subtle point: WordPress can try to raise memory limits for image processing, but only if your hosting environment permits it. WordPress can’t override a hard limit imposed by the server. The function responsible for this behaviour is documented here: wp_raise_memory_limit().

WordPress also has an image_memory_limit filter that controls the memory limit used for image manipulation, defaulting to the higher of WP_MAX_MEMORY_LIMIT and the original PHP memory_limitimage_memory_limit).

The takeaway is simple: if your logs show memory or timeout errors, you either need smaller uploads/batches, or you need more server headroom (or both).

Fix 4: Check disk space and temporary storage (the silent killer)

This one gets missed because it doesn’t always produce a friendly error.

During upload, WordPress may need space for:

• The original file
• One or more scaled versions
• All intermediate sizes
• Temporary working files (PHP temp directory)

If your hosting account is close to its storage quota, or your temporary directory is constrained, uploads can fail in ways that look like “WordPress is crashing”. If you’re seeing random failures even with small images, it’s worth ruling this out with your host.

Fix 5: Rule out plugin/theme conflicts (especially anything that touches images)

Anything that hooks into image uploads can add work to each upload. Common culprits are:

• Image optimisation plugins (extra processing on upload)
• Watermarking plugins
• Media offload/CDN plugins
• Security plugins that deeply inspect uploads
• Import/migration tools doing background processing

The safe way to test is on a staging site: disable the suspected plugin(s), try the same upload, and check the logs. If the crash disappears, you’ve at least narrowed it down. I wouldn’t recommend switching off security tooling on a live shop “just to see” unless you really know what you’re doing and you’ve agreed the risk.

Fix 6: If you change WooCommerce image settings, regenerate thumbnails afterwards

This is more about preventing headaches later than preventing the initial crash, but it’s linked. WooCommerce product images rely on the sizes configured for the shop, and themes often assume certain sizes exist.

If you change product image dimensions (or swap out a lot of source images), WooCommerce’s own docs recommend regenerating thumbnails via WooCommerce → Status → Tools (Fixing blurry product images).

Just be aware that regenerating thumbnails is itself a CPU/memory-heavy job. Don’t run it at the same time as a massive media upload, and ideally do it off-peak.

The “easy mode” option: use a workflow that batches uploads properly

If you frequently need to add lots of images (new product ranges, seasonal updates, catalogue tidy-ups), doing it via the standard Media Library uploader can be a pain. Even if the server is well specced, one bad batch can waste your afternoon.

I built a bulk media uploader plugin for handling lots of uploads in a more controlled way because I kept running into this on real client stores: the normal uploader encourages you to throw everything at it at once, and that’s exactly when you hit timeouts and memory spikes.

It’s not a substitute for having enough server resources (nothing is), but it’s a more practical day-to-day workflow when you’re regularly dealing with batches of product photography.

Wrap-up: the real cause is usually “too much processing at once”

If WordPress media upload crashing is what brought you here, the key idea to remember is this: the upload is only the start. The heavy bit is the image processing and the multiplication effect of multiple thumbnail sizes across multiple images.

What I’d do first, in order:

1. Upload smaller batches.
2. Resize images before uploading (don’t feed it massive originals unless you need them).
3. Check logs to confirm whether it’s memory, timeouts, web server limits, or disk space.
4. Adjust server limits with your host if the site genuinely needs bigger uploads.
5. Test for plugin/theme conflicts if it still fails.

If you just want an easier workflow for big batches, Bulk Media Uploader is the “less painful” option I made for that exact situation.

If you’re stuck, or you’ve got logs you can’t make sense of, drop me a line via the contact page and I’ll point you in the right direction.