You try to upload a theme, a video, or a backup — and the server answers 413 Request Entity Too Large. The 413 Request Entity Too Large fix is about raising a size limit: the file you are sending is bigger than the server is configured to accept. The tricky part is that the limit can live in several places — Nginx, Apache, PHP, or even Cloudflare — and you must raise the right one. This 2026 guide shows you how to find which layer is blocking and fix each.
Here is the key concept. A 413 is the server refusing the request body before your application ever sees it. On the common WordPress stack there are three gates in a row: the web server (Nginx’s client_max_body_size, default just 1 MB), PHP (upload_max_filesize, default 2 MB; post_max_size, default 8 MB), and any proxy or CDN in front (Cloudflare free/pro caps uploads at 100 MB). The smallest gate wins — you must raise every gate the upload passes through.
What Causes the 413 Error
- Nginx’s 1 MB default:
client_max_body_sizeunset means 1 MB — the most common cause on Nginx servers. - PHP’s tiny defaults:
upload_max_filesize = 2Mandpost_max_size = 8Mout of the box. - Changed one layer, forgot the other: raising PHP but not Nginx (or vice versa) leaves the error in place.
- Cloudflare’s 100 MB cap: uploads through a proxied domain cannot exceed it on Free/Pro plans.
- Editing the wrong php.ini: servers have separate ini files for CLI, FPM, and Apache — the web one is what matters.
- Forgot to reload: config changes do nothing until the service reloads.
How to Fix 413 Request Entity Too Large: 7 Steps
Step 1: Find which layer is blocking
Check the response headers or server error log: an Nginx 413 page names Nginx; a PHP “POST Content-Length exceeds the limit” message names PHP. If the site is behind Cloudflare and the file is over 100 MB, suspect Cloudflare first. Diagnose before changing anything.
Step 2: Raise the Nginx limit
With server access, add client_max_body_size 64M; to the http, server, or location block in your Nginx config, then test with nginx -t and reload with systemctl reload nginx. Put it in the SSL server block too if uploads go over HTTPS.
Step 3: Raise the PHP limits
In the correct php.ini (the FPM/web one — verify with phpinfo()), set:
upload_max_filesize = 64Mpost_max_size = 64M
Rules of thumb: post_max_size must be ≥ upload_max_filesize, and both should be ≤ the Nginx limit. Restart PHP-FPM afterwards. On shared hosting without ini access, try .user.ini or .htaccess php_value directives — or ask your host.
Step 4: Check Cloudflare and proxies
If the domain is proxied through Cloudflare, uploads cannot exceed 100 MB on Free/Pro plans — this is a hard Cloudflare limit, raisable only on Enterprise. Workarounds: upload via a direct (unproxied) subdomain, or split the file. Also check any reverse proxy in front of the app for its own body-size limit.
Step 5: Fix it in WordPress specifically
For Media Library uploads, you can also raise limits via wp-config.php with @ini_set('upload_max_filesize', '64M') lines, or use a plugin like “Increase Maximum Upload File Size”. Confirm the new limit shows under Media → Add New (“Maximum upload file size”).
Step 6: Reload everything and test
After every change: nginx -t && systemctl reload nginx, restart PHP-FPM, then retry the exact upload that failed. Verify the limit in phpinfo() output. If it still fails, re-check which layer answered — one gate is still smaller than the file.
Step 7: Do not just set it to 2 GB
Raise limits to what you actually need (64–128 MB covers most WordPress use), not the maximum. Huge limits invite abuse and memory problems — PHP still loads the upload into memory, so keep memory_limit comfortably above your upload size. For large media workflows, consider chunked or direct-to-storage uploads instead. If uploads fail differently, see our 408 Request Timeout fix.
How to Prevent 413 Errors
Set sane limits (64M) at every layer when you first configure a server, and document them — the classic 413 comes from a forgotten default months later. Compress videos and images before upload, and for routinely large files use chunked upload plugins. A quick upload test after any server migration catches limit mismatches early. Monitor upload failures with a free site health tool so users are not the ones who discover the limit.
Conclusion
413 means one of your gates is too small: raise Nginx’s client_max_body_size, PHP’s upload_max_filesize/post_max_size, and check Cloudflare’s 100 MB cap — then reload and retest. Match the layers, keep limits sane, and uploads flow. For more server-error fixes, keep reading the KamiWeb blog.