Fix “HTTP 413 Payload Too Large” in Smush Bulk Smush

Why this error shows up

HTTP 413 Payload Too Large means your server understood the request, but rejected it because the body was bigger than its configured limit.

When it happens during Bulk Smush, it usually comes down to one of these:

• Your PHP limits (upload_max_filesize, post_max_size, etc.) are too low for the images Smush is trying to optimize in one go.
• Your web server or proxy (Nginx, Apache, LiteSpeed, load balancer) has a low request body limit, like client_max_body_size on Nginx.
• A CDN or WAF in front of the site is blocking large or repeated Smush requests.
• You have a few very large originals (huge hero images, camera originals) that push the request over the edge.

The good news: this is a configuration limit, not a permanent Smush bug. Once the limits and image sizes are under control, Bulk Smush will run normally again.

Step 1: Confirm it is a size limit problem

Before changing settings, make sure 413 really is the cause.

Do this:

1. Run Smush → Bulk Smush and start Bulk Smush.
2. When the error appears, open your browser’s developer tools and check the Network tab.
3. Look for a failed request related to Smush (often an admin or REST request) with status 413 or text like Request Entity Too Large or Payload Too Large.
4. In WordPress, go to Media → Add New and note the Maximum upload file size shown at the bottom of the upload box.

If you see 413 in the network log and a relatively small max upload size (for example 2 MB, 8 MB, or 16 MB), you are dealing with a server limit that is too low for your current images.

Step 2: Raise PHP upload and POST limits (most common fix)

On many shared hosts, the 413 error during Bulk Smush is caused by PHP limits that are too low for larger images or for the way Smush batches requests.

Goal: bump these values

• upload_max_filesize
• post_max_size
• memory_limit (to give PHP breathing room)
• max_execution_time and max_input_time (so long operations do not time out mid request)

As a starting point, many image heavy sites use something like:

upload_max_filesize = 64M
post_max_size       = 64M
memory_limit        = 256M
max_execution_time  = 300
max_input_time      = 300

Option A: Using your hosting control panel

If your host gives you a PHP editor or “MultiPHP INI Editor” in cPanel or a similar panel, use that.

1. Open your hosting control panel and look for PHP Settings, PHP Options, or PHP INI.
2. Select the domain that runs your site.
3. Increase upload_max_filesize and post_max_size to at least the size of your largest images, plus a bit of room.
4. Optionally set memory_limit to 256M and increase the time limits if they are very low.
5. Save changes and restart PHP if your host requires it.

Option B: Using .htaccess (Apache and LiteSpeed)

If you are on Apache or LiteSpeed and cannot find a PHP editor, you can often raise limits in .htaccess.

1. Connect via FTP or your file manager and open the root folder of your WordPress site.
2. Edit the .htaccess file (back it up first).
3. Add this near the top, below WordPress’ own rules:

<IfModule mod_php.c>
  php_value upload_max_filesize 64M
  php_value post_max_size 64M
  php_value memory_limit 256M
  php_value max_execution_time 300
  php_value max_input_time 300
</IfModule>

4. Save the file and reload Bulk Smush.

If you get a 500 Internal Server Error right after editing .htaccess, remove those lines and ask your host to set the values for you instead. Some servers do not allow php_value overrides.

Step 3: Raise web server or proxy limits (Nginx, load balancer, CDN)

If PHP limits look fine, the 413 may come from the web server or a proxy in front of it.

On Nginx based servers

Nginx uses client_max_body_size to control how big a single request body can be.

1. Ask your host where you can adjust Nginx config for your site (for example nginx.conf or a per site include).
2. In the http, server, or location block for your site, add or increase:

client_max_body_size 64m;

3. Save the config and reload Nginx.

This is the exact directive many Smush users had to increase when they saw 413 errors behind an Nginx reverse proxy.

Behind a proxy or CDN

If you are using a reverse proxy, a container proxy, or a CDN like Cloudflare, there may be a separate upload limit there as well.

• Check your proxy or CDN dashboard for any max upload size or request body size setting and raise it to match your PHP limits.
• If you cannot find such a setting, send your host or DevOps team a short note such as: “Bulk image optimization with Smush is returning HTTP 413 Payload Too Large. Please increase the request body limit for admin and Smush requests on this site.”

Step 4: Make Smush send smaller work units

Even with higher limits, it is smart to reduce how heavy each request is, especially if you have huge originals from a camera or design tool.

Resize overly large originals

1. In WordPress, open Smush → Settings or the section where you can configure Resize my original images.
2. Set a realistic max width and height for your site (for example 1920 by 1080 or similar).
3. Save and then run Bulk Smush again so Smush creates smaller originals instead of trying to optimize enormous source files.

Smaller originals mean smaller thumbnails and smaller request bodies during Bulk Smush.

Deal with a few giant images separately

If Bulk Smush always fails around the same point, you may have a few outlier images that are much larger than the rest.

1. Check your Media Library for images with very high dimensions or multi megabyte sizes.
2. Download those files and resize or compress them locally in an editor (Photoshop, Affinity, GIMP, or an online compressor).
3. Re upload them to WordPress, replacing the originals.
4. Run Bulk Smush again.

This takes pressure off the server without forcing you to raise limits indefinitely.

Step 5: Check security plugins and WAF rules

Sometimes the 413 response or a similar block comes from a firewall layer, not from plain PHP or the web server.

• If you use a security plugin (Wordfence, Sucuri, iThemes, etc.), temporarily disable its firewall features or learning mode and try Bulk Smush again.
• If your host or CDN provides a WAF, look for logs that mention blocked requests from the admin area during Bulk Smush.
• Whitelist your own IP address or the specific Smush endpoint your host identifies as safe.

If Bulk Smush works with the firewall disabled but fails when you re enable it, you will need a permanent allow rule for Smush related requests.

If you cannot change server settings yourself

Not comfortable editing configs or do not have access to them? That is normal on many managed or shared hosts.

In that case, contact your host with a message like this:

Hi,

When I run the Smush Bulk Smush tool in WordPress, I get an HTTP 413 "Payload Too Large" error.

Can you please:
- Increase the PHP limits (upload_max_filesize, post_max_size, memory_limit, max_execution_time), and
- Increase any web server or proxy request body limit (such as client_max_body_size on Nginx)

so that Bulk Smush can process batches of images without hitting size limits?

Thank you.

Verification checklist

Once you have raised limits and tamed the biggest images, check that:

• Bulk Smush runs without “HTTP 413 Payload Too Large” interruptions.
• The Maximum upload file size in Media → Add New matches the limits you set.
• No Nginx or Apache logs show 413 responses during Bulk Smush runs.
• Your site still feels responsive and does not time out while processing images.

Still stuck?

For AI help

Hit Continue Chat below and tell me:

1. Your host and whether you are on Apache, LiteSpeed, or Nginx (if you know).
2. The current values for upload_max_filesize and post_max_size.
3. Whether you are using a CDN or proxy (Cloudflare, reverse proxy, or similar).
4. Roughly how large your biggest images are in megabytes.

I will walk you through a configuration that fits your setup.

For expert human help

Scroll down to the contact form below. Enter your name, email, and WordPress needs. Atiba will get back to you as soon as possible.