How to fix the 413 Request Entity Too Large error on WordPress?

You’re trying to upload a file to your WordPress site and you get “413 Request Entity Too Large”? Basically, your server is telling you that the file you’re trying to send is too big for it.

It’s an error I run into regularly with my clients, whether it’s an image that is too heavy, the installation of a large theme or plugin, a WooCommerce product import, or even a backup restore. The good news is that it can be fixed in a few minutes.

I’ll show you how, starting with the simplest method.

The 413 error belongs to the family of HTTP 4xx errors (errors related to the client’s request). It appears when you send the server a file or data that exceeds the maximum allowed size.

The message can be displayed in different ways depending on your browser and your server:

• 413 Request Entity Too Large
• 413 Payload Too Large
• HTTP Error 413
• Request Entity Too Large – The requested resource does not allow request data

It’s the same problem every time: your file is too big for what your server accepts. The default limit varies by host, but it is often around 2 MB to 10 MB. If you try to upload a 50 MB video or a 30 MB theme, of course it gets stuck.

In more than 10 years of WordPress troubleshooting, these are the cases where I run into this error most often:

• Uploading images or videos: you try to upload an uncompressed HD photo or a video from the media library
• Installing a theme or plugin: some premium themes like Avada are over 20 MB, and the server blocks the upload
• WooCommerce import: you import a product CSV file that is a bit too big, or product images in bulk
• Backup restore: you restore a backup via a plugin like UpdraftPlus and the backup file exceeds the limit. It can also cause a memory error on top of that

In all these cases, the solution is either to reduce the file size or to raise the server’s upload limit. I’ll show you both approaches.

This is the method I use first with my clients. No need to touch the code, everything is done from your host’s interface.

If you’re with o2switch (or another host equipped with cPanel), you have access to it. With OVH, there is no cPanel and php.ini can’t be edited on shared hosting: if the limit blocks you, reduce the file size or ask OVH support for the limits of your plan. Here are the steps:

1. Log in to your cPanel
2. Look for the “Software” section
3. Click “Select PHP Version” (or “MultiPHP INI Editor” at some hosts)
4. Select your domain, then click the “Options” tab (sometimes you first need to go through “Extensions” then “Options” depending on the cPanel version)
5. Find the fields upload_max_filesize and post_max_size. They are drop-down menus: select 64M for the first and 128M for the second
6. Save the changes

That’s it. Go back to your site and try the upload again. In 90% of cases it’s fixed.

Warning: always set post_max_size larger than upload_max_filesize. post_max_size is the total size of the request sent to the server (which includes the file + the form data). If both are identical, it can still block.

If your host doesn’t offer this option in cPanel, move on to the next methods.

If you don’t have access to the PHP setting via cPanel, you can use the .htaccess file. It’s the most documented method on the internet and it works on Apache servers (most shared hosting).

Connect via FTP (with FileZilla for example) or through your host’s file manager. The file .htaccess is located at the root of your WordPress site.

Add these lines at the end of the file, just before #END WordPress:
php_value upload_max_filesize 64M
php_value post_max_size 128M
php_value max_execution_time 300
php_value max_input_time 300
Important: each directive must be on its own line. If you put them all on a single line, it will cause a 500 error on your site.

Save and try the upload again.

max_execution_time and max_input_time are there to avoid a timeout if the file is big and the upload takes time. 300 seconds (5 minutes) is generally enough.

On some modern hosts that use PHP-FPM, the php_value directives in .htaccess are ignored. It’s frustrating because you make the change, reload, and nothing changes.

In that case, the real solution is to create a file .user.ini at the root of your WordPress site (in the same place as wp-config.php).

Create the file via your host’s file manager or over FTP, and add these lines:
upload_max_filesize = 64M
post_max_size = 128M
max_execution_time = 300
max_input_time = 300
Save and wait a few minutes. The .user.ini file isn’t read in real time by the server, there is a refresh delay (usually 5 minutes). After that delay, try the upload again.

Technical note: contrary to what you read on quite a few blogs, changing upload_max_filesize and post_max_size via @ini_set() in wp-config.php or functions.php does not work for upload limits. PHP checks the file size before running WordPress, so these directives come too late. .user.ini is read by PHP at startup, which is why it works.

If nothing works or if you don’t want to modify configuration files, there is still the workaround: upload the file directly via FTP.

For example, if a plugin is too big to be installed via the back office:

1. Unzip the plugin’s .zip file on your computer
2. Connect to your site via FTP
3. Upload the plugin folder to wp-content/plugins/
4. Go back to your WordPress back office, go to Plugins, and activate the plugin

Same principle for a theme: upload the folder to wp-content/themes/

This method completely bypasses the server’s upload limit since an FTP transfer has no size restriction.

If your site runs on an Nginx server (not Apache), .htaccess doesn't work. You need to edit the Nginx configuration file.

Look for the file nginx.conf and add or change this directive:
client_max_body_size 64M;You can place it in the http block (for the whole server), in the server block (for a single site) or even in a location block (for a specific path). If you're on a VPS, I recommend putting it in the server block of the site concerned rather than touching the global config.

Then restart Nginx. This operation requires root access to the server, so if you're on shared hosting you won't be able to do it yourself. Contact your host in that case, they will do it for you.

Rather than raising the limits every time, here are a few good habits:

• Compress your images before uploading them. Free tools like TinyPNG or Imagify reduce the size of your images with no visible loss of quality. A 5 MB image can often go down to 200 KB
• Avoid uploading videos directly to WordPress. Host them on YouTube or Vimeo and add them with an embed. Your server will thank you
• For large WooCommerce imports, split your CSV file into several small files instead of sending a single 50 MB one
• Check your current upload limit by going to WordPress > Media > Add New. The limit is shown at the bottom of the page (“Maximum upload file size: XX MB”)

And if you raise the limits anyway, do it reasonably. Don’t set 500 MB just “in case”. On shared hosting, you share resources with other sites. 64 MB for upload and 128 MB for post is more than enough for most uses.

Is your site showing another error? I also explain how to fix the Maximum execution time exceeded error and the 429 Too Many Requests error.

The 413 error is simply your server telling you “this file is too big for me”. You have 4 ways to fix it:

1. cPanel (the simplest, my favorite)
2. .htaccess (the most documented, for Apache servers)
3. .user.ini (when .htaccess is ignored, especially with PHP-FPM)
4. FTP upload (the workaround, always available)

And remember to reduce the size of your images by converting them to WebP before uploading them, it will keep you from running into this error again and again.

If you’re struggling or if the error persists anyway, contact me. It’s the kind of problem I fix in 5 minutes for my clients.