The “413 Request Entity Too Large” error occurs when a web server blocks an upload exceeding its size limits, often during large image or plugin uploads. Fix this by increasing the client_max_body_size in your Nginx configuration and updating both upload_max_filesize and post_max_size within your PHP settings to allow larger files.
Emergency Stop-Gap: If you need to upload a large file immediately and cannot access your server’s configuration files, use an FTP/SFTP client (like FileZilla) or a File Manager provided by your hosting control panel. This allows you to upload the file directly into the
/wp-content/directory, bypassing the web server’s size restrictions entirely.
Before You Start
Before you start editing any configuration files, grab a complete backup of both your website and database. This is essential; even a minor typo in these server-level .ini files can cause the web server to fail during startup, which would take your site offline immediately. If you are on a managed host, check if they provide a “PHP Selector” or similar tool first. Using their built-in interface is much safer than manual editing and keeps your site stable while we make these adjustments.
Related guide: How to Fix 504 Gateway Timeout Error on Nginx and Apache
What does a 413 error mean for your site?
When a user hits a 413 error while trying to upload a theme, plugin, or media file in WordPress, the issue isn’t actually with your website’s software—it means your Nginx web server is intercepting the request and stopping it before it ever reaches the PHP engine. This isn’t a WordPress bug; it’s a server-level gatekeeper doing exactly what it was designed to do by blocking what it perceives as an “oversized” request.
In most cases, this happens because default Nginx configurations limit uploads to very small windows, typically 1MB or 10MB. When you attempt to upload something larger, such as high-resolution video or a heavy plugin, Nginx sees the header size and terminates the connection immediately. To resolve this, you must update the client_max_body_size directive within your Nginx configuration files.
Related guide: Fix GoDaddy Managed WordPress Migration Failure
Why is my upload failing with a 413 error?
You are running into this issue because your server architecture has two separate checkpoints that must both be adjusted to accommodate larger files. If either of these “gates” is set too low, the upload will fail before it ever reaches your dashboard.
-
The Nginx Layer: This is the specific reason you are seeing the “413” status code. In this context, Nginx acts as the front door to your server. The
client_max_body_sizedirective determines exactly how large of a request the web server is willing to accept from a user. If the file exceeds this limit, Nginx rejects it instantly. -
The PHP Layer: Even if you successfully pass through the Nginx gate, your site’s backend—the PHP engine—has its own internal restrictions. Because WordPress relies on PHP to process and move files into your media library, the
upload_max_filesizeandpost_max_sizesettings must be large enough to handle your specific file. If these aren’t synced with your Nginx settings, the upload will either fail or appear to hang indefinitely.
To fix this, both layers must be updated to a value that exceeds your largest expected file size.
| Configuration Layer | Directive(s) | Purpose |
|---|---|---|
| Nginx Web Server | client_max_body_size | Controls the maximum size of the HTTP request body allowed by the web server. |
| PHP Engine | upload_max_filesize | Defines the maximum size of an individual uploaded file in PHP. |
| PHP Engine | post_max_size | Defines the maximum size of the entire POST request (must be $\ge$ upload_max_filesize). |
Related guide: Fix .htaccess Redirect Loop: Guide to ERR_TOO_MANY_REDIRECTS
How do I fix the Nginx client_max_body_size limit?
If you are running into a 413 error, it means your server is actively blocking an upload because it exceeds its predefined size limit. It’s an annoying hurdle when you’re trying to get content live, but we can clear this right now by adjusting the Nginx configuration files. Depending on how your specific server environment is structured, these settings are typically located in /etc/nginx/nginx.conf or within a specific site-level file inside /etc/nginx/sites-available/.
Where can I find and edit the Nginx config file?
You’ll need to access your server via SSH. Once you are logged in, open your configuration file using a text editor like nano:
sudo nano /etc/nginx/nginx.confOnce inside the file, look for the http, server, or location blocks. If you don’t see client_max_body_size listed anywhere, you will need to add it manually. You should set this value to something larger than your expected maximum upload—for instance, 128M is a solid standard for most sites.
http {
...
client_max_body_size 128M;
...
}How do I apply changes via command line?
After you have saved your edits to the file, do not skip the testing phase. You must verify that the syntax is correct before restarting the service to ensure the site stays online:
sudo nginx -t
sudo systemctl restart nginxIf your hosting setup uses a control panel like cPanel or Plesk instead of direct command-line access, you won’t need to use the terminal. In those cases, you can usually find these settings within the “Nginx Manager” section or by navigating to the specific configuration area for your domain name within the dashboard.
How do I increase the PHP upload limits?
It is incredibly frustrating when you are trying to get a specific plugin or a high-resolution image onto your site and the system blocks you with an error. While we have already addressed the Nginx 413 error—which acts as the gatekeeper for the server—WordPress will still struggle to process large files if the underlying PHP settings remain at their default limits. These defaults are often set very low, typically around 2MB or 32MB, which is insufficient for modern web development.
To fix this, we need to modify your php.ini file (or a .user.ini file, depending on how your specific host manages configurations). This tells the PHP engine exactly how much data it is allowed to process in a single request.
Editing the php.ini file
Locate your active php.ini file. On most systems, you will find this in directories such as /etc/php/[version]/apache2/ or /etc/php/[version]/fpm/. You need to find and update the following lines:
upload_max_filesize = 128M
post_max_size = 128M
memory_limit = 256MThere is a critical rule here: your post_max_size must always be equal to or larger than the upload_max_filesize. If you set the post size lower than the upload limit, the server will reject the request before it even attempts to process the file, causing your uploads to fail regardless of your Nginx settings.
Applying changes for PHP-FPM
If your environment uses PHP-FPM (which is the standard for most modern Nginx configurations), the server won’t recognize these new limits until you restart the service. Think of this as refreshing the system so it can load the new “rules” we just wrote.
Run the following command to apply the changes:
# Replace 8.x with your actual version, e.g., 8.1 or 8.2
sudo systemctl restart php8.x-fpmCan I fix this through my WordPress hosting panel?
Most shared hosting providers restrict your access to the nginx.conf file for security reasons, which can feel like a roadblock when you are trying to resolve an upload issue. When you encounter these local restrictions, there are two alternative ways to bypass them and get your site functioning correctly.
Using .htaccess (Apache/Litespeed fallback)
If your server architecture utilizes an Apache backend with Nginx acting as a reverse proxy, you can often set the necessary limits via your .htaccess file. While this won’t resolve a hard-coded Nginx 413 error if the file exceeds the gateway’s limit, it ensures that the PHP environment is properly configured to handle the files once they pass through the initial gate.
php_value upload_max_filesize 128M
php_value post_max_size 128M
php_value max_execution_time 300
php_value max_input_time 300Using wp-config.php for specific overrides
Depending on your specific environment or the plugins you have active, it is sometimes possible to define these limits directly within your wp-config.php file. This method is less reliable than editing core configuration files, but it serves as a viable workaround in many cases. You must place these lines before the “That’s all, strip the whitespace” line to ensure they are processed correctly:
@ini_set( 'upload_max_filesize' , '128M' );
@ini_set( 'post_max_size', '128M' );Why isn’t it working after I changed the settings?
It is incredibly frustrating to go through the effort of updating your configuration files only to see that 413 error persist. When this happens, it usually points to one of three specific technical hurdles: you are editing a file the server isn’t actually looking at, the service hasn’t refreshed its memory to recognize your changes, or an external gatekeeper like Cloudflare is blocking the request before it even reaches your server.
Verify the correct configuration path
A frequent point of confusion in Nginx setups is the distinction between global and site-specific configurations. You might be making perfect adjustments in nginx.conf, but the server may be pulling its instructions from a specific file located in /etc/nginx/sites-enabled/. To find out exactly which file is controlling your site’s behavior, run this command:
grep -r "server_name" /etc/nginx/sites-enabled/Verify the service restart
Updating a configuration file is only the first half of the process. The server software needs to be told to reload those instructions into its active memory. If you modify a file but don’t restart the underlying service, the old limits remain in place. After making any changes, you must run systemctl reload nginx or systemctl restart php-fpm to force the system to recognize your new settings.
Check for Proxy interference
If your site sits behind Cloudflare, they act as a buffer between your visitors and your server. Cloudflare imposes strict limits on request sizes—typically 100MB for their free tier. If your file exceeds that threshold, Cloudflare will drop the connection immediately. Because this happens at the proxy level, you cannot bypass it by modifying your nginx.conf. In these instances, you must change your workflow to use a chunked upload plugin or an alternative upload method to get the file past the gateway.
What common mistakes make this problem worse?
One common trap is increasing upload_max_filesize while leaving post_max_size at its default. Because every file sent to the server is wrapped inside a “POST” request, the server will drop the connection if that outer container isn’t large enough to hold the actual file. To keep the connection stable, you must ensure both values are increased together.
Another hurdle is the max_execution_time setting. Large files require significant time for the server to process and move into your permanent directory. If PHP hits its standard 30-second timeout during this transition, the upload will “fail” even though you successfully bypassed the 413 error by increasing the size limits. In this scenario, the script isn’t being blocked by a size cap; it’s simply running out of time before it can finish moving the file.
When should you call a professional?
It can be incredibly stressful when your site isn’t behaving, but some issues are buried deep in the server infrastructure and require an expert to pull them out. You should reach out to your hosting provider or a systems administrator if:
- You have edited the
nginx.conffile but the server refuses to restart (Syntax error). - You cannot find where your
php.iniis located because of a complex multi-server setup. - You are using a managed WordPress host (like WP Engine or Kinsta) where you do not have SSH access, and they refuse to manually adjust the limits for you.
A professional can quickly identify if a firewall or a Load Balancer (like HAProxy) is providing an additional layer of restriction that your local configuration cannot override.