Error 413 means the server rejected the request. The reason is that the size of the request (a file, an API call, or a form with attachments) exceeded the configured limit. So what should you do if you run into error 413? It all depends on whether you have access to the server configuration or not. Below we'll cover what this error actually is, why it happens, and — most importantly — proven ways to fix it.
What error 413 means
Error 413 Request Entity Too Large is an HTTP response indicating that the request sent to the server exceeded the allowed limit. It's important to understand that this isn't really an "error" in the traditional sense — it's a response the server sends back. In practice, this often looks like: a user tries to upload a 20-30 MB archive to their WordPress site, but the server has a 10 MB limit set. The request gets blocked, and the server returns error 413. Simple as that.

Request Entity Too Large typically shows up in the following situations:
trying to upload a large image, video, or archive to the site;
submitting a site form with a large attachment;
uploading a large file through the control panel;
sending a large POST request.
It's crucial to distinguish error 413 from other HTTP errors. For comparison, take errors 404 and 500. The first means the requested resource wasn't found, while the second indicates an internal server error. Error 413 doesn't point to any technical problem on the site's end — in fact, there isn't one. It's simply the server's response to an attempt to upload a file or attachment that exceeds the allowed maximum. In other words, the site has a specific limit configured, and it can't be exceeded without changing the settings. When the uploaded object hits that limit, the server responds with Request Entity Too Large.
What causes error 413
Often, a webmaster who runs into this issue heads straight to PHP settings to raise the limit (upload_max_filesize, post_max_size). But after making the change, they're left puzzled — the limit was raised, yet the problem persists. Why does this happen?
The reason is simple: the limit can be set in several places at once:
Nginx. A site running behind Nginx gets a maximum request body size limit through the client_max_body_size directive.
Apache. Here too, the limit is set at the web server level, specifically through the LimitRequestBody directive.
PHP. On PHP-driven sites, as mentioned above, limits are set via upload_max_filesize (size of an individually uploaded file) and post_max_size (limit on the overall POST request).
CMS, plugins. If you're using plugins, they may theoretically impose their own request size limit. As for CMS platforms, WordPress lets you set additional custom limits.
CDN. Have a CDN connected? Then the request might get limited at the PoP level before it even reaches the origin server.
So why, after changing the limit in Nginx, does the problem sometimes remain? You raised the limit on the Nginx side, but the PHP or CDN limit is still at its old value. That's exactly why the server keeps returning error 413 even after you've adjusted the settings in one particular place.
How to fix error 413 on shared hosting or in a control panel
If your site is hosted on shared hosting, you typically don't have root access. If that's your case, start by checking the PHP settings in your server's control panel.
You'll need to find the following parameters:
upload_max_filesize = 150M
post_max_size = 170MYou'll need to look for this setting in your control panel. Depending on the panel, it looks the same but is located in a different place. Look for the following:
PHP Settings or MultiPHP INI Editor — in cPanel.
PHP Settings for domain — in Plesk.
PHP Settings — in DirectAdmin.
PHP Parameters — in FastPanel.
Web domain and PHP settings — in HestiaCP.
Set the value based on the actual size of the files you upload. It's recommended to set post_max_size higher than upload_max_filesize, if only because a POST request usually includes more than just a single file.
If your server runs Apache, you'll often find the following entry in .htaccess:
php_value upload_max_filesize 100M
php_value post_max_size 110MBut this doesn't work reliably in every configuration. For example, if the server uses PHP-FPM, this approach won't take effect. Another possibility is that your provider has blocked changes to PHP parameters via .htaccess altogether.
As for provider-side restrictions, it's not uncommon on shared hosting for the provider to enforce their own cap on the maximum upload size. You might see a 128 MB limit in the control panel, while the hosting server itself caps uploads at 64 MB. In that case, no matter what you change, nothing will help.
If you need full control over your project, check out Leneex's VPS plans. We don't impose limits like that.
How to fix error 413 on a VPS (Nginx and Apache)
Having admin rights on a VPS lets you change the configured limits yourself. But exactly what and where to change depends on your OS, configuration, and website setup. Let's go over the most common cases.
Nginx
Nginx uses the client_max_body_size directive. To let the server accept requests up to 150 MB, add the following:
server {
server_name YOUR_SITE.com
client_max_body_size
150M;
# other settings
}After making the change, check the configuration:
nginx -tThen reload the configuration with:
systemctl reload nginxBut if there are still limits set at the PHP level, you'll need to change those too. Adjusting the Nginx configuration alone won't be enough.
PHP
Here you need to check upload_max_filesize and post_max_size. Set the parameters like this:
upload_max_filesize = 150M
post_max_size = 170MOnce you've made the changes, restart PHP-FPM:
systemctl restart php8.3-fpmMake sure to use your actual PHP version at the end — it might be php8.2-fpm instead.
Apache
On Apache, the limit is set via the LimitRequestBody directive.
It looks like this:
<VirtualHost *:80>
ServerName YOUR_SITE.com
LimitRequestBody
104857600
# other settings
</VirtualHost>The limit is specified in bytes; the value above corresponds to 100 MB in bytes. If you're using .htaccess, whether you can change this directive there depends on the server's own configuration.
Once the changes are made, reload the configuration:
apachectl configtestThen run:
systemctl reload apache2It's important to remember that with an Nginx+Apache+PHP-FPM stack, the limit needs to be raised at every level. If you only raise it in Nginx, nothing will change — the fix simply won't take effect. This is where the advantages of VPS hosting really shine compared to the restrictions of a shared hosting control panel. With a Leneex VPS, you get root access, so you can make changes without any limitations imposed by the hosting provider.
How to verify the limit was raised correctly
After making all the changes, check that the configuration works step by step:
Check the configuration for errors. If there aren't any — great, move on to the next step.
Restart the relevant service.
Check the PHP parameters.
Then upload a file that previously failed due to the body size limit.
If the problem persists, check the Nginx, Apache, and PHP logs. Without log entries, any guesswork is just that — guesswork.
Also check the CDN, if you have one connected.
Always check every level: more often than not, users forget to change the limit somewhere. That's the main reason the server keeps returning error 413.
Conclusion
The 413 Request Entity Too Large error does not necessarily indicate a technical problem with the server itself. It is the server's response to an attempt to upload a file that exceeds the permitted size limit. Shared hosting can be more restrictive than a virtual server because the provider or control panel may impose limits that you cannot change, even if you need to. In this case, the solution may be to migrate to a VPS.
With root access, you can easily adjust the limits and make changes to Nginx, Apache, and PHP yourself. If your website regularly encounters the 413 error while you are using shared hosting, it may be time to switch to a VPS. Check out the virtual server plans available on our website. You will get root access and be able to configure the server to accommodate the required file sizes and API requests. You won't have to ask your hosting provider to approve every change.







