413 Request Entity Too Large means exactly what it says: what you sent was bigger than the server agreed to accept. You will meet it uploading images, video, database dumps or backup files.
The difficulty is not the fix, it is the number of places that need fixing. The size limit is set at two or more independent layers — the web server and the language runtime — and a request has to clear all of them. Raise one and the behaviour is completely unchanged, which is why so many people conclude they edited the wrong file and go hunting somewhere else entirely.
This guide covers every layer in the order worth changing them, plus a couple of traps that leave the error in place even after you have edited everything correctly.
How many limits are there?
This table is the core of the article. Understand it and you can solve almost every instance of this error yourself.
| Layer | Setting | Common default |
|---|---|---|
| Nginx | client_max_body_size | 1 MB |
| Apache | LimitRequestBody | Unlimited (but hosts often set it) |
| PHP | upload_max_filesize | 2 MB |
| PHP | post_max_size | 8 MB |
| Cloudflare (proxied) | Plan limit | 100 MB on the free plan |
| Your application | Its own limit | Varies |
Fixing it in Nginx
On Nginx this is the layer you hit first, because the default of 1 MB is smaller than a photo from a modern phone.
Add a client_max_body_size directive. It can live in the http block (server-wide), a server block (one site) or a location block (one path) — for example 64m or 128m, sized to what you actually need.
Always validate with "nginx -t" before reloading. Restarting with a syntax error means the service does not come back and the site goes down immediately, turning a small problem into an outage.
One gotcha: if the directive appears in several places, the most specific block wins. If you raised it in http and nothing changed, look for an older value still sitting in the server or location block that handles your upload path.
Fixing it in PHP — and the trap almost everyone hits
PHP has two settings that must be changed together, and this is where fixes most often come up short.
upload_max_filesize caps each individual file. post_max_size caps the entire request body. The rule is that post_max_size must be larger than upload_max_filesize, because the request carries form data alongside the file.
And if your form uploads several files at once, post_max_size has to cover their combined total, not just the largest one. Someone who sets both to 50 MB and then uploads three 20 MB files will still see the error.
Where to change it: php.ini if you have access, otherwise .user.ini or .htaccess depending on what your host allows. If you run PHP-FPM you must restart php-fpm, not just reload the web server — this single detail is why many people believe their edits are being ignored.
Verify the values took effect with phpinfo() or "php -i" rather than assuming. Systems often have several php.ini files, and the one actually loaded may not be the one you just edited.
The Cloudflare trap
If your site is proxied through Cloudflare there is another limit that does not live on your server at all.
The free plan caps request size at roughly 100 MB, and paid plans have their own ceilings. Anything larger is rejected before it ever reaches you, which means no amount of server-side configuration will help.
Confirming it is easy: upload directly to the server, bypassing Cloudflare, by temporarily pointing the domain at the real IP in your hosts file. If that works, Cloudflare is the limiter.
The practical fix is to stop sending large files through the proxy — use a separate subdomain with proxying turned off for uploads, or have the browser upload straight to object storage. For genuinely large files that is the better architecture anyway.
Changed everything and it still fails? Check these
- You restarted the wrong service. php.ini changes need php-fpm restarted; nginx.conf changes need nginx reloaded. Doing one but not the other is extremely common.
- An older value survives in a more specific block. You raised client_max_body_size in http, but the location block handling uploads still carries the original.
- The file you edited is not the one being loaded. Check phpinfo() for the loaded configuration file path and the current values — hosts frequently override them elsewhere.
- The application has its own cap. WordPress, DirectAdmin and many frameworks enforce limits independent of the server.
- The upload is timing out rather than being rejected for size. If it exceeds max_execution_time or max_input_time you get a different failure — usually a 504 or a blank page — which reads like the fix did not work.
If you are on shared hosting and cannot change it
Worth stating plainly, because this is a limit configuration cannot solve.
On shared hosting you can usually adjust the PHP side through .user.ini or .htaccess, but client_max_body_size is a server-level directive shared by every customer on the machine, so providers do not expose it. If the host caps you at 8 MB, that is the ceiling.
You have three options. Ask the provider to raise it — some will. Change the upload path entirely, sending files to object storage or via SFTP and having the application collect them. Or move to a VPS where every configuration file is yours.
For genuinely large files the second option is usually best regardless of your hosting, because pushing hundreds of megabytes through a single HTTP request is fragile no matter how high you set the limits.
Want to control every configuration layer yourself?
Cloud NVMe VPS with full root access — edit nginx.conf and php.ini directly, no host-imposed ceiling. From ฿150/month.
Frequently Asked Questions
I raised upload_max_filesize and uploads still fail. Why?
Almost always because post_max_size was not raised too, or because Nginx client_max_body_size is still at its default. The limits stack and the lowest one decides. Verify with phpinfo() that your values actually took effect, and remember to restart php-fpm rather than only reloading the web server.
What should I set the limit to?
Whatever your real workload needs plus a small margin — 32 to 64 MB covers phone photos comfortably. Never set it to unlimited on a public site; that lets anyone push arbitrarily large bodies at you until disk or memory is exhausted.
What is the difference between 413 and 414?
413 means the request body is too large, which happens on file uploads and big form posts. 414 URI Too Long means the URL itself is too long, usually from an unusually long query string. Different causes, different places to fix.
My site is behind Cloudflare and server changes did nothing.
Cloudflare enforces its own request-size cap (around 100 MB on the free plan) before traffic reaches you. Test by uploading with Cloudflare bypassed. If that succeeds, route large uploads around the proxy — an unproxied subdomain, or direct-to-object-storage uploads.
GUIDES
Related articles
Keep reading on similar topics
502 Bad Gateway — What It Means and How to Fix It
A 502 means one server asked another server for the page and got back something it could not use. This guide explains which two machines are involved, how 502 differs from 500 and 504, and the order to work through the causes so you find the real one first.
Read more
504 Gateway Timeout — And Why Raising the Timeout Is the Wrong Fix
A 504 means the backend was reachable but too slow to answer in time. The instinctive fix — raise the timeout — turns a fast error into a slow one and solves nothing. This guide covers what actually causes 504s and how to fix the cause instead of the symptom.
Read more
429 Too Many Requests — Causes and How to Fix It
The first question is not how to fix it — it is who is doing the limiting. Your own server, the CDN in front of it, and the API you are calling all return the same 429, and the fix is different for each.
Read more