A 413 error appears when a server refuses a request because the data being sent exceeds its configured size limit, and the fix always comes down to finding which layer is actually enforcing that limit — the web server, PHP, or a reverse proxy in front of everything. Here’s how to diagnose and fix it across the most common setups.
What’s Actually Causing the Error
Unlike errors caused by permissions or routing issues, a 413 response is triggered specifically by size restrictions designed to protect server resources and maintain performance. The tricky part is that these limits exist at multiple layers simultaneously — your web server, your application (like PHP), and any reverse proxy or CDN sitting in front of your site can each impose their own ceiling. Fixing the error isn’t about removing limits entirely, but about understanding where they’re enforced and adjusting them safely for your specific use case.
Fix 1: Increase the Nginx Limit
If you’re running Nginx, this is very often the actual culprit. Nginx ships with a conservative 1MB upload limit by default, which is the most common reason for the 413 error on Nginx specifically.
To fix it, locate your Nginx configuration file — usually at /etc/nginx/nginx.conf, or in your site-specific block under /etc/nginx/sites-available/. Inside the http, server, or location block, add:
client_max_body_size 128M;
Adjust the number to whatever limit actually fits your use case, then reload Nginx to apply the change:
sudo systemctl reload nginx
Fix 2: Increase the Apache Limit
On Apache, the equivalent setting is LimitRequestBody, set inside the relevant <Directory> or <Location> block:
<Location />
LimitRequestBody 20971520
</Location>
That value is in bytes, so it’s worth using a megabytes-to-bytes conversion to land on a specific limit rather than guessing. After making the change, restart Apache:
sudo systemctl restart apache2
If you don’t have direct access to httpd.conf — common on shared hosting — the same fix can often be applied through a .htaccess file instead.
Fix 3: Adjust PHP’s Own Upload Limits
Even after fixing your web server’s limit, PHP enforces its own separate ceiling that can still block large uploads. Edit your php.ini file and adjust:
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 300
max_input_time = 300
memory_limit = 128M
A key detail worth remembering: post_max_size needs to be equal to or larger than upload_max_filesize, since post data size affects file uploads directly — if you increase one without the other, you can end up right back at the same error.
If you’re on WordPress specifically and don’t have server-level access, these same PHP values can often be set via a .htaccess file using php_value directives, or through your hosting control panel’s PHP settings interface, which frequently offers a simpler way to adjust these limits without touching config files directly.
Fix 4: Check Your CDN or Reverse Proxy
This is the layer most guides skip, and it can undo everything else you’ve fixed. If you’re using a CDN, this restriction could also be imposed by the CDN’s own configuration, so it’s worth double-checking there specifically if server and PHP-level changes don’t resolve the issue. A CDN or reverse proxy sitting in front of your actual server can enforce its own request size cap independently of anything set on the origin server itself.
Fix 5: For Genuinely Massive Files, Skip HTTP Upload Entirely
If you’re dealing with files large enough that raising every limit still isn’t practical — think multi-gigabyte media files — there’s a more direct workaround. For massive files, you can skip HTTP upload entirely by moving the file via SFTP or your host’s file manager instead, then pointing the application at the resulting server path rather than uploading through the browser at all.
Verifying the Fix Actually Worked
After making changes at any layer, restart or reload the relevant service and re-attempt the upload that originally failed. It’s worth knowing that dashboards in tools like WordPress often display the current upload limit, but they rarely override it — the number shown on the Media screen simply reflects whatever PHP is currently configured to, so adjusting PHP is what actually changes that displayed value.
Preventing It From Happening Again
- Set practical limits rather than maximizing everything. Extremely high limits can leave your server more exposed to abuse or resource exhaustion from oversized requests.
- Compress large files before upload. Lossy and lossless compression on images and video can keep typical uploads well under your configured limits in the first place.
- Choose import tools that support chunked uploads. For large media libraries or bulk imports, chunked upload support avoids hitting size limits on any single request.
- Educate users on your platform’s actual limits if the site accepts user-submitted files, so failed uploads don’t get mistaken for a broken site.
Join The Discussion
Which layer turned out to be the actual culprit when you last ran into a 413 error — Nginx, Apache, PHP, or a CDN sitting in front of everything? Share what limits you ended up settling on and whether you had to adjust more than one layer before the error actually cleared. If you’ve dealt with this on a shared hosting plan without direct server access, it’d be great to hear which control panel settings actually got you there.
