HTTP 413 Request Entity Too Large: Root Causes, Fixes, and Server Configuration Guide

The HTTP 413 Request Entity Too Large error is a server-side response status code that occurs when an incoming request body — most commonly a file upload — exceeds the maximum payload size configured at the web server, reverse proxy, or application layer. The server actively rejects the request before processing it, returning a 413 status to the client.

This error is not a client-side bug. It is a deliberate enforcement mechanism built into web servers like Nginx and Apache, PHP runtime configurations, and application-level middleware. Understanding exactly which layer is enforcing the limit — and how to target the correct configuration directive — is the difference between a clean fix and hours of troubleshooting.

Why HTTP 413 Errors Occur: A Layer-by-Layer Breakdown

A file upload request passes through multiple processing layers before it reaches your application. Any one of these layers can independently reject the request with a 413 response. Diagnosing the error correctly requires identifying which layer is responsible.

Layer 1: Web Server Directives

Nginx enforces upload size limits through the client_max_body_size directive. Its default value is 1MB, which is aggressively low for most modern applications. This directive can be set in the http, server, or location block context, and the most specific block wins.

Apache uses the LimitRequestBody directive, which defaults to 0 (unlimited) in most distributions — but hosting providers routinely override this in their global or virtual host configurations to a restrictive value. Apache also processes .htaccess files, which means the limit may be enforced at the directory level without touching the main configuration.

Layer 2: PHP Runtime Configuration

PHP introduces two independent directives that both must be satisfied for a large upload to succeed:

• upload_max_filesize — the maximum size of a single uploaded file
• post_max_size — the maximum size of the entire POST request body, which must be equal to or larger than upload_max_filesize

A common misconfiguration is setting upload_max_filesize = 50M while leaving post_max_size at its default of 8M. The POST body limit is evaluated first, so the upload silently fails before the file size limit is even checked.

There is also a third directive that is frequently overlooked: max_input_time, which defines how long PHP will wait to receive input data. On slow connections uploading large files, this timeout can trigger a failure that manifests as a 413 or a blank response.

Layer 3: Reverse Proxies and Load Balancers

If your infrastructure uses a reverse proxy — HAProxy, Varnish, Cloudflare, or an Nginx instance acting as a proxy in front of another server — that proxy layer has its own body size limits. A 413 returned by Cloudflare, for example, has a hard limit of 100MB on free and Pro plans, and no amount of server-side configuration will override it. Always check your proxy layer's response headers to identify the origin of the 413.

Layer 4: Application and CMS Restrictions

Content management systems and frameworks apply their own upload restrictions on top of the server and PHP layers. WordPress reads the effective upload limit from PHP's runtime values but also enforces its own media library constraints. Some WordPress plugins add additional validation layers. Custom PHP applications may use $_FILES validation logic that imposes stricter limits than the server allows.

Nginx Configuration: Fixing 413 at the Web Server Level

For Nginx, the fix requires modifying client_max_body_size in the correct configuration context. Editing the http block applies the limit globally; editing a server or location block applies it only to that virtual host or endpoint.

# Global setting — applies to all virtual hosts
http {
    client_max_body_size 100M;
}

# Per-virtual-host setting — preferred for multi-tenant environments
server {
    listen 80;
    server_name example.com;
    client_max_body_size 100M;

    # Granular control — apply only to the upload endpoint
    location /wp-admin/async-upload.php {
        client_max_body_size 256M;
    }
}

After editing, validate the configuration syntax before reloading:

nginx -t && systemctl reload nginx

Critical edge case: If Nginx is acting as a reverse proxy in front of PHP-FPM or another application server, you must also check the proxy_read_timeout and proxy_send_timeout directives. A large upload that takes longer than the timeout will be terminated mid-transfer, producing a 413 or 504 error depending on the proxy behavior.

Apache Configuration: Fixing 413 at the Web Server Level

Apache's LimitRequestBody directive accepts a value in bytes. The directive can be placed in httpd.conf, a VirtualHost block, a Directory block, or an .htaccess file.

# In httpd.conf or VirtualHost block
LimitRequestBody 104857600

# In .htaccess (if AllowOverride is enabled for the directory)
LimitRequestBody 104857600

The value 104857600 equals 100MB (100 × 1024 × 1024). After modifying httpd.conf or a virtual host file, restart Apache:

apachectl configtest && systemctl restart apache2

Important nuance: On shared hosting environments, .htaccess modifications may be ignored if the hosting provider has set AllowOverride None in their server-level configuration. In that case, only the hosting provider can change the limit. This is one of the primary technical reasons to consider moving to a VPS Hosting environment where you have full root access to the server configuration.

PHP Configuration: Fixing 413 at the Runtime Level

The php.ini file is the authoritative source for PHP upload limits. The correct file to edit depends on your PHP execution model (mod_php, PHP-FPM, CLI). Use phpinfo() or php --ini to identify which php.ini is actually loaded.

; Minimum required changes for large file uploads
upload_max_filesize = 128M
post_max_size = 128M
max_input_time = 300
max_execution_time = 300
memory_limit = 256M

After editing php.ini, restart the appropriate service:

# For PHP-FPM
systemctl restart php8.2-fpm

# For Apache with mod_php
systemctl restart apache2

Alternative methods when php.ini is inaccessible:

If you are on a shared hosting plan without direct php.ini access, you may be able to override PHP settings using:

1. A .user.ini file in the web root (works with PHP-FPM):

upload_max_filesize = 64M
post_max_size = 64M

1. An .htaccess directive (works with mod_php only):

php_value upload_max_filesize 64M
php_value post_max_size 64M

1. Runtime PHP code (limited effectiveness, not recommended for production):

@ini_set('upload_max_filesize', '64M');
@ini_set('post_max_size', '64M');

Note that ini_set() cannot override upload_max_filesize or post_max_size at runtime in PHP 7.x and later — these directives are evaluated before script execution begins. The .user.ini or .htaccess methods are far more reliable.

WordPress-Specific Fix for 413 Errors

WordPress displays its effective upload limit in the Media > Add New screen. If the limit shown is lower than what you have configured in php.ini, the issue is typically that WordPress is reading from a different PHP process or that a caching layer is serving stale configuration data.

Add the following to wp-config.php to explicitly define the upload size:

@ini_set( 'upload_max_size', '128M' );
@ini_set( 'post_max_size', '128M' );
define( 'WP_MEMORY_LIMIT', '256M' );

For WordPress Multisite installations, the network-level upload size is controlled separately under Network Admin > Settings > Network Settings > Max upload file size. This setting is independent of PHP limits and must be configured in addition to the server-level changes.

Comparison: Where to Fix 413 Based on Hosting Environment

Diagnosing Which Layer Is Returning the 413

Before applying any fix, confirm the source of the 413 response. Use curl with verbose output to inspect the response headers:

curl -v -X POST -F "file=@/path/to/largefile.zip" https://example.com/upload

Examine the Server response header and any X-Powered-By or CF-RAY headers. A CF-RAY header indicates the 413 originated at Cloudflare, not your server. A response from nginx/1.x.x points to the Nginx layer. No Server header may indicate a load balancer or WAF upstream of your application.

Also check your server error logs immediately after triggering the 413:

# Nginx
tail -f /var/log/nginx/error.log

# Apache
tail -f /var/log/apache2/error.log

# PHP-FPM
tail -f /var/log/php8.2-fpm.log

When Server Configuration Is Not Enough: Infrastructure Considerations

For applications that routinely handle large file transfers — video platforms, backup systems, medical imaging, large-scale e-commerce product catalogs — hardcoding high upload limits into a shared server configuration is not a sustainable architecture. Consider these alternatives:

• Chunked uploads: Split large files into smaller chunks on the client side using libraries like Resumable.js or Uppy. Each chunk is within the server's limit, and the server reassembles them. This bypasses 413 entirely.
• Direct-to-object-storage uploads: Generate a pre-signed URL for S3-compatible storage and have the client upload directly, bypassing your web server entirely. The web server only handles the metadata transaction.
• Dedicated upload endpoints: Configure a separate location block in Nginx with a higher client_max_body_size specifically for upload routes, keeping the default limit restrictive for all other endpoints.

For compute-intensive workloads involving large file processing — video transcoding, machine learning inference on uploaded data — a GPU Hosting environment provides the processing capacity to handle both the upload and the subsequent computation without bottlenecks.

If your application requires a managed control panel environment with full PHP configuration access, a VPS with cPanel gives you the MultiPHP INI Editor in WHM, allowing per-domain PHP directive overrides without touching the command line.

Security Considerations When Raising Upload Limits

Increasing upload limits without corresponding security hardening introduces real attack surface. A server that accepts 500MB POST requests is a viable target for denial-of-service attacks that exhaust disk I/O, memory, or connection pools.

Implement the following controls alongside any limit increase:

• Rate limiting on upload endpoints: In Nginx, use limit_req_zone to restrict upload frequency per IP.
• File type validation: Never rely on the client-supplied MIME type. Validate file signatures (magic bytes) server-side.
• Upload directory permissions: The directory receiving uploads must not be web-accessible or executable. Store uploads outside the document root.
• Virus scanning: Integrate ClamAV or a similar scanner into the upload pipeline for any publicly accessible upload endpoint.
• Authenticated uploads only: Require authentication before accepting large payloads. Unauthenticated large upload endpoints are trivially abused.

For production environments handling sensitive uploaded data, pairing your hosting infrastructure with properly configured SSL Certificates ensures that file transfers are encrypted in transit, preventing interception of uploaded content.

Technical Decision Matrix: Choosing the Right Fix

Practical Checklist for Resolving HTTP 413

• Identify the layer returning the 413 using curl -v and server error logs before making any changes
• On Nginx, set client_max_body_size in the most specific applicable block (location preferred over server over http)
• Ensure post_max_size is always greater than or equal to upload_max_filesize in php.ini
• Increase max_input_time and max_execution_time for large files on slow connections
• Verify .htaccess overrides are permitted (AllowOverride All or AllowOverride Options) before relying on them
• Check all proxy layers independently — CDN, load balancer, and application server each enforce limits separately
• After any configuration change, reload (not just restart) the relevant service and clear any opcode or page cache
• For WordPress Multisite, configure the network-level upload limit in addition to PHP directives
• Implement rate limiting and file type validation before raising limits on public-facing upload endpoints
• If shared hosting prevents configuration access, migrate to a VPS Hosting or Dedicated Servers environment for full control

Frequently Asked Questions

What is the default upload limit in Nginx that causes a 413 error?

Nginx defaults client_max_body_size to 1MB. Any request body exceeding 1MB will return a 413 unless this directive is explicitly increased in the Nginx configuration.

Can I fix a 413 error without server root access?

On shared hosting, you can attempt fixes via .htaccess (Apache only, if AllowOverride permits) or a .user.ini file (PHP-FPM only). However, if the hosting provider has set restrictive global limits, these methods will be ineffective and you will need to contact support or upgrade to a VPS plan.

Why does my upload fail even after increasing upload_max_filesize in php.ini?

The most common cause is that post_max_size remains at its lower default value. PHP evaluates the POST body size limit before the individual file size limit, so the upload is rejected before upload_max_filesize is even checked. Always increase both directives simultaneously.

Does Cloudflare cause 413 errors?

Yes. Cloudflare enforces its own request body size limits: 100MB on Free and Pro plans, 200MB on Business, and 500MB on Enterprise. If your request exceeds these limits, Cloudflare returns a 413 before the request reaches your origin server. No server-side configuration change will resolve this — you must either upgrade your Cloudflare plan, use direct upload bypass (pre-signed URLs), or implement chunked uploads.

How do I permanently fix 413 in WordPress on a cPanel server?

Use WHM's MultiPHP INI Editor to increase upload_max_filesize and post_max_size for the specific PHP version and domain. Then verify the change is reflected in WordPress under Media > Add New. For WordPress Multisite, additionally update the maximum upload size under Network Admin > Settings. No .htaccess or wp-config.php changes are required when using WHM's INI editor directly.