How to Fix 413 Request Entity Too Large Error

By ErrorFix · Updated October 14, 2026 · 5 min read

What 413 Request Entity Too Large means

The 413 status is the server's way of saying "your request was fine, but the body is too big." It shows up most often when you upload a file: a video through the WordPress media uploader, a backup restore file, a large attachment sent to a contact-form endpoint, or a POST to an API that carries a payload. The server reads the Content-Length header, sees it exceeds the configured ceiling, and refuses the whole request — which is why the error appears instantly instead of partway through the upload.

What makes 413 confusing is that the ceiling can live in several different places at once. Your request can pass through Cloudflare, then nginx, then PHP-FPM, each with its own independent limit. The effective cap is the smallest one in the chain, so the fix is finding which layer is the bottleneck and raising it — not randomly changing settings until something sticks.

Common causes

• nginx's client_max_body_size at its 1 MB default: when nginx sits in front of PHP, its default one-megabyte cap rejects almost any real upload before WordPress ever sees the request — the most common cause on VPS and dedicated servers.
• PHP's upload limits too small: upload_max_filesize and post_max_size default to values like 2 MB and 8 MB on many hosts. The WordPress media uploader shows the resulting cap under the drop zone at Media, then Add New.
• Apache's LimitRequestBody set low: the VirtualHost can carry a strict byte cap (or a distro default) that kills large uploads with a 413. Shared hosts rarely let you change this one.
• Cloudflare's 100 MB edge ceiling: on Free and Pro plans, Cloudflare rejects any request body over 100 MB at the edge. Your server never sees it, so server-side tuning cannot help.
• An application or API-level limit: a form plugin, a REST endpoint, a load balancer, or a reverse proxy in front of your app can enforce its own max body size — check the endpoint's own settings when the server stack looks unlimited.

How to fix 413 Request Entity Too Large — step by step

The whole fix takes about thirty minutes: identify the layer, raise its limit above your file size, and retest.

1. Find which layer caps the request body. Note the exact size of the file that fails and where the error appears. A WordPress media upload that fails below the stated max points at PHP's upload limits. A failure above one megabyte on a server running nginx points at client_max_body_size, which defaults to just 1 MB. A failure only over roughly 100 MB on a Cloudflare-proxied site points at Cloudflare's edge limit. Knowing the layer tells you exactly which setting to change.
2. Raise PHP's upload limits. On cPanel hosting, open MultiPHP INI Editor, select your site's PHP version, and set upload_max_filesize and post_max_size above your file size, with memory_limit larger than post_max_size. Without a panel, add these three lines to a php.ini or .user.ini file in your site root: upload_max_filesize = 64M, post_max_size = 64M, and memory_limit = 128M. Wait a minute for PHP to pick up the change, then open Media, then Add New and confirm the stated max upload size went up.
3. Raise nginx's client_max_body_size. On your VPS or dedicated server, open the site's server block in /etc/nginx/sites-available/ or /etc/nginx/conf.d/ and add client_max_body_size 64M; inside the server { } block. Then run sudo nginx -t to check the configuration and sudo systemctl reload nginx to apply it. The 1 MB default rejects most real uploads before they ever reach WordPress, so this one setting fixes the 413 error for the majority of nginx sites.
4. Raise Apache's LimitRequestBody. On an Apache server you control, open the site's VirtualHost configuration and add LimitRequestBody 67108864 for a 64 MB ceiling, or LimitRequestBody 0 to remove the cap entirely. Then run sudo apachectl configtest and sudo systemctl restart apache2. On shared hosting this directive is server-level and .htaccess edits are ignored, so ask your host to raise it if uploads keep failing.
5. Work around Cloudflare's upload ceiling. Cloudflare's Free and Pro plans reject request bodies over 100 MB at the edge with a 413, and that ceiling cannot be raised on those plans. Split files larger than 100 MB into smaller parts before uploading, or temporarily grey-cloud the site's DNS record in Cloudflare's DNS settings so the upload goes straight to your server, then switch the orange cloud back on afterwards.
6. Retest with a measured upload and lock the change in. Upload a test file of the exact size that used to fail, from Media, then Add New, with the Cloudflare proxy on if you use it. If it lands in the library, the fix is complete. Keep each limit as small as your largest legitimate file needs — an unlimited body size invites abuse — and write the new values down so the next server migration or PHP upgrade does not silently reset them.

Did this fix it? Quick checklist

• The failing file size is known, and every layer's limit (PHP, nginx/Apache, Cloudflare) sits above it
• nginx: client_max_body_size is set and nginx reloaded without configuration errors
• PHP: upload_max_filesize and post_max_size are raised, with memory_limit larger than post_max_size
• A test upload of the previously failing size lands in the media library, proxy and all

One more spot to check if it still fails: create a phpinfo.php file with <?php phpinfo(); ?>, load it, and read the actual loaded values for upload_max_filesize and post_max_size — many hosts silently override your .user.ini with a global policy. Delete the phpinfo.php file as soon as you have the numbers, since it exposes server details. And if the upload passes on a direct connection but fails behind a reverse proxy or load balancer, check that middle layer's body-size setting too — every hop in the chain has its own ceiling.