413 Request Entity Too Large: How to Fix It

Last tested: October 22, 2026 · By Alex

A 413 Request Entity Too Large error means the server refused the request because the body is bigger than it is configured to accept. You usually see it when uploading a theme, plugin, image, video, or backup file, or when an API sends a large JSON payload.

The newer name for this status is 413 Content Too Large (earlier specs called it Payload Too Large). The fix is the same: find which layer has the lowest size limit and raise it, or make the request smaller. The tricky part is that there are often several layers: Cloudflare, NGINX, Apache, PHP, and the application itself.

Quick Fix

• Try a smaller file to confirm the error is size-related.
• Compress images or videos before uploading, or zip files more efficiently.
• NGINX: raise client_max_body_size.
• Apache: raise or remove LimitRequestBody.
• PHP: raise upload_max_filesize and post_max_size.
• Reload the web server and PHP-FPM after every change.
• Cloudflare: check your plan’s upload limit (100 MB on Free and Pro).
• For very large files, upload via SFTP or WP-CLI instead of the browser.

What Is 413 Request Entity Too Large?

413 is an HTTP client error status code. The server is saying that the request content is larger than the limits it allows. It may close the connection, and if the limit is temporary it can include a Retry-After header.

Related errors:

• 414 URI Too Long: the URL is too long, not the body.
• 431 Request Header Fields Too Large: the headers are too big.
• 400 Bad Request: sometimes used instead of 413 by proxies that do not send specific codes.

One detail that confuses people: when PHP limits are the bottleneck, you often do not get a 413. PHP silently drops the data, and WordPress shows a message such as “The uploaded file exceeds the upload_max_filesize directive in php.ini” or “The link you followed has expired”. A real 413 page almost always comes from the web server or a proxy.

Why 413 Request Entity Too Large Happens

1. NGINX client_max_body_size Is Too Low

The NGINX default is 1 MB. Any request body larger than that gets 413 Request Entity Too Large with an “nginx” footer. This is the single most common cause on VPS setups.

2. Apache LimitRequestBody

Apache’s LimitRequestBody caps request bodies. Since Apache 2.4.54 the default is 1 GB, but control panels and hardening guides often set it much lower.

3. PHP Upload Limits

upload_max_filesize limits a single file and post_max_size limits the whole POST body. post_max_size must be larger than upload_max_filesize, because the form includes more than just the file.

4. Reverse Proxy or Load Balancer Limits

If NGINX sits in front of Apache, or a load balancer sits in front of NGINX, each layer has its own limit. Raising it on the backend does nothing if the front layer still rejects the request.

5. CDN Limits

Cloudflare limits request body size by plan: 100 MB on Free and Pro, 200 MB on Business, and 500 MB by default on Enterprise. Bigger uploads get a 413 from Cloudflare before they reach your server.

6. Application or WAF Limits

ModSecurity’s SecRequestBodyLimit, security plugins, and frameworks (for example Express body parsers or Laravel validation) can enforce their own size caps.

How to Fix 413 Request Entity Too Large Step by Step

1. Identify Which Layer Returns the Error

Look at the error page and headers. An “nginx” footer means NGINX. A Server: cloudflare header with a Cloudflare-branded page means Cloudflare. Apache error pages say “Apache”. Reproduce with curl:

dd if=/dev/zero of=test.bin bs=1M count=20
curl -i -F "file=@test.bin" https://example.com/upload-test/

Then check the error logs. NGINX logs client intended to send too large body, which confirms the cause.

2. Raise client_max_body_size in NGINX

Set it in the http, server, or location block:

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

sudo nginx -t && sudo systemctl reload nginx

A more specific block overrides a general one. If http says 64M but a location block says 1M, the location value wins for that path. Search all included files:

sudo grep -R "client_max_body_size" /etc/nginx/

3. Raise LimitRequestBody in Apache

In the virtual host, a <Directory> block, or .htaccess (the value is in bytes; 0 means unlimited):

# 64 MB
LimitRequestBody 67108864

sudo apachectl configtest && sudo systemctl reload apache2

4. Raise PHP Limits

Find which php.ini is loaded. The CLI may use a different file than PHP-FPM, so check with a phpinfo() page or:

php --ini
php -i | grep -E "upload_max_filesize|post_max_size"

Then set:

upload_max_filesize = 64M
post_max_size = 72M
memory_limit = 256M
max_execution_time = 300

Restart PHP-FPM:

sudo systemctl restart php8.3-fpm

On Apache with mod_php, you can use .htaccess instead:

php_value upload_max_filesize 64M
php_value post_max_size 72M

Do not put php_value lines in .htaccess on PHP-FPM or LiteSpeed setups that do not support them, it may cause a 500 error. Use a .user.ini file in the site root instead:

upload_max_filesize = 64M
post_max_size = 72M

.user.ini changes are picked up after user_ini.cache_ttl, which is 300 seconds by default.

5. Use the Hosting Panel on Shared Hosting

On shared hosting you usually cannot edit server configs. Look for MultiPHP INI Editor in cPanel, PHP Configuration in hPanel, or a similar option in your panel. Server-level limits like client_max_body_size can only be raised by the host.

6. Upload Large Files Another Way

For themes, plugins, and backups, uploading through the browser is not required:

# Install a plugin zip with WP-CLI
wp plugin install /path/to/plugin.zip --activate

# Import media already uploaded via SFTP
wp media import /path/to/video.mp4

Advanced Troubleshooting

NGINX in Front of Apache

With an NGINX reverse proxy, set client_max_body_size on NGINX and make sure Apache and PHP allow at least the same size. Also check proxy timeouts, because big uploads take time:

location / {
    proxy_pass http://127.0.0.1:8080;
    client_max_body_size 64M;
    proxy_read_timeout 300s;
    proxy_request_buffering off;
}

proxy_request_buffering off streams the upload to the backend instead of buffering it on disk first. That is useful for large files.

Check ModSecurity

If logs mention ModSecurity, raise the limits:

SecRequestBodyLimit 67108864
SecRequestBodyNoFilesLimit 1048576

Kubernetes and Ingress Controllers

For ingress-nginx, the setting is an annotation: nginx.ingress.kubernetes.io/proxy-body-size: "64m". Editing NGINX inside the container is overwritten on restart.

Large JSON Payloads

For APIs, check framework limits (for example express.json({ limit: '10mb' }) in Node.js) and consider pagination or chunked uploads instead of a single huge request.

Match the Error Message to the Layer

• “413 Request Entity Too Large” with an nginx footer: NGINX client_max_body_size.
• “The requested resource does not allow request data with POST requests, or the amount of data provided in the request exceeds the capacity limit”: Apache LimitRequestBody.
• “The uploaded file exceeds the upload_max_filesize directive in php.ini”: PHP upload_max_filesize.
• “The link you followed has expired” in WordPress: usually post_max_size exceeded, so PHP dropped the whole form, including the nonce.
• Cloudflare-branded 413 page: the plan’s body size limit.

Knowing which message you got saves you from editing four config files when only one is the problem.

WordPress-Specific Causes

• Check the current limit: Media → Add New shows “Maximum upload file size”. Tools → Site Health → Info → Server shows the PHP values.
• Theme and plugin uploads: premium theme zips can be large. Upload the unpacked folder to wp-content/themes/ via SFTP, or use WP-CLI.
• Backup restores: backup plugins can split archives or import from cloud storage. That avoids browser upload limits entirely.
• Multisite: Network Admin → Settings → Max upload file size adds another limit on top of PHP.
• Image upload errors: if uploads fail with “HTTP error” rather than a 413, see Error Uploading Image in WordPress.

The Cloudflare Angle

If Cloudflare returns the 413, raising limits on your server will not help. Options:

• Upload through a hostname that is not proxied (gray cloud DNS record), for example upload.example.com, protected by its own access control.
• Use chunked uploads so each request stays under the limit. Many upload libraries support this.
• Upload directly to object storage (R2 or S3) with pre-signed URLs instead of through your origin.
• Upgrade the plan if large single uploads are a core feature.

Prevention Tips

• Keep limits consistent across layers: CDN ≥ proxy ≥ web server ≥ PHP post_max_size > upload_max_filesize.
• Set limits to what the site actually needs. Unlimited body sizes make abuse easier.
• Compress and resize images before uploading.
• Document custom limits in your server notes so they survive migrations.
• After changing PHP versions, check limits again. Each version has its own php.ini.

When to Contact Support

Contact your host if you are on shared or managed hosting and the error page shows NGINX or LiteSpeed, or if you raised PHP limits but Site Health still shows old values. Give them the file size you need to upload, the exact error text, and the time of the failed upload.

Frequently Asked Questions

Final Thoughts

A 413 error is always about a size limit somewhere in the request path. Find the layer that rejects the request first (Cloudflare, NGINX, Apache, or PHP), then raise that limit and every one behind it. For very large files, skip browser uploads and use SFTP, WP-CLI, or direct-to-storage uploads.

Related HTTP Errors

• Error Uploading Image in WordPress
• 414 Request-URI Too Long
• 431 Request Header Fields Too Large
• 400 Bad Request
• How to Fix Website Errors (full guide)