Error 413 Request Entity Too Large: What It Means and How to Fix It

HTTP status 413 Request Entity Too Large (renamed to 413 Content Too Large in RFC 7231) means the server rejected the request because the request body exceeds the configured size limit. In plain terms: the uploaded file or submitted data is larger than the server configuration allows.

This error appears in the browser in several scenarios: uploading images or video in a CMS, submitting a form with an attachment, importing a database via phpMyAdmin, or installing plugins through the WordPress admin interface.

The error always originates on the server side — the client is not at fault. The restriction can come from the web server (Nginx or Apache) or from PHP. Identifying which one is blocking the request matters, because changing one parameter while the limit sits elsewhere accomplishes nothing.

How to Identify the Source of the Limit

Before touching any config — check the logs. They will show which component rejected the request.

Nginx:

tail -n 50 /var/log/nginx/error.log

A line containing client intended to send too large body confirms the limit is in Nginx.

Apache:

tail -n 50 /var/log/apache2/error.log

PHP:

grep -i "upload\|post" /var/log/php*.log

If the logs show nothing — the error may be returned by a load balancer or proxy in front of the server (HAProxy, Cloudflare, AWS ALB).

Fixing the Error in Nginx

By default Nginx limits the request body to 1 MB via the client_max_body_size directive. When a request exceeds this limit, Nginx immediately returns 413 without passing anything to PHP.

Open the main configuration:

nano /etc/nginx/nginx.conf

Or the config for a specific virtual host:

nano /etc/nginx/sites-available/example.com

Find or add the directive in the appropriate block:

Globally — inside the http {} block:

http {
    client_max_body_size 64m;
}

For a specific domain — inside the server {} block:

server {
    server_name example.com;
    client_max_body_size 64m;
}

For a specific location only (e.g., upload endpoint):

location /upload {
    client_max_body_size 256m;
}

Setting the value to 0 removes the limit entirely — not recommended on public-facing servers.

After making changes — validate the syntax and reload:

nginx -t && systemctl reload nginx

Fixing the Error in Apache

In Apache, the limit is set by the LimitRequestBody directive. By default it imposes no restriction (value 0), but it may be explicitly set in the config or in .htaccess.

In the configuration file (/etc/apache2/apache2.conf or inside a VirtualHost):

<VirtualHost *:80>
    ServerName example.com
    LimitRequestBody 67108864
</VirtualHost>

The value is in bytes. 67108864 = 64 MB.

In .htaccess (if AllowOverride permits it):

LimitRequestBody 67108864

Reload Apache:

systemctl reload apache2

If Apache sits behind an Nginx proxy — the limit needs to be raised in both configs. Nginx checks first.

Fixing the Error in PHP

Even when the web server passes the request through, PHP has its own upload and POST size limits set in php.ini.

Find the active configuration file:

php --ini | grep "Loaded Configuration"

Open it and locate three directives:

nano /etc/php/8.2/fpm/php.ini

; Maximum size of a single uploaded file
upload_max_filesize = 64M

; Maximum size of all POST data (must be >= upload_max_filesize)
post_max_size = 128M

; Maximum script execution time in seconds
max_execution_time = 300

post_max_size must be greater than or equal to upload_max_filesize — otherwise PHP will reject the upload before even checking the file size.

After editing, restart PHP-FPM:

systemctl restart php8.2-fpm

Or Apache with mod_php:

systemctl restart apache2

Verify the settings were applied — create a info.php file:

<?php phpinfo();

Open it in the browser and search for upload_max_filesize and post_max_size in the output.

Fixing via .htaccess (PHP with mod_php)

If direct access to php.ini is not available (shared hosting), some parameters can be overridden in .htaccess:

php_value upload_max_filesize 64M
php_value post_max_size 128M
php_value max_execution_time 300

This works only with Apache running mod_php. With PHP-FPM, these directives in .htaccess have no effect.

WordPress: an Additional Detail

WordPress checks the upload limit independently and displays it under Media → Add New. If it shows "Maximum upload file size: 2 MB" — WordPress is taking the lowest of three values: upload_max_filesize, post_max_size, and memory_limit.

Add to wp-config.php:

@ini_set('upload_max_filesize', '64M');
@ini_set('post_max_size', '128M');
@ini_set('memory_limit', '256M');

Or in .htaccess before # BEGIN WordPress:

php_value upload_max_filesize 64M
php_value post_max_size 128M

Common Mistakes When Troubleshooting

Changed php.ini but the error persists — the limit is also set in Nginx or Apache. Both places need to be updated.

Changed Nginx but the limit did not apply — forgot to run nginx -t && systemctl reload nginx. Or the directive is in the wrong block (e.g., in a location while the request goes to a different path).

Multiple php.ini files on the server — separate files exist for CLI, FPM, and Apache. Changing the CLI version has no effect on web requests.

Error 413 is returned by Cloudflare — Cloudflare Free and Pro plans have a 100 MB limit on file uploads through proxied domains. This is a Cloudflare restriction, not a server one — it can only be raised on an Enterprise plan or by disabling proxying for the specific domain.

Quick Reference

Summary

Error 413 is fixed by raising the limit in whichever component set it: Nginx, Apache, or PHP. If the server is behind Cloudflare — check their limits as well. After any changes, always reload the relevant service and verify via phpinfo() or a test upload.