A Practical Guide to Fixing the Error 413 Request Entity Too Large

That moment you hit "upload" on a big file, only to be met with a "413 Request Entity Too Large" error, is a familiar frustration. It feels like you’ve hit a dead end, but the fix is usually straightforward. This isn't a problem with your browser or a mistake you've made; it's the web server itself putting on the brakes.

Think of it as a bouncer at a club with a strict capacity limit. The server has been configured to reject any incoming request—be it a file upload, a form submission, or an API call—that's bigger than it's prepared to handle.

What the 413 Request Entity Too Large Error Really Means

The HTTP 413 Request Entity Too Large status code is a clear message from the server: the data you sent is over its size limit. This is a common hurdle, especially in applications that handle media uploads or large data payloads. For a deeper dive into how these requests are built, our guide on understanding cURL for HTTP requests in hosting environments is a great resource.

This limit isn't arbitrary—it's a crucial security measure. Web servers like Nginx and Apache set default request size limits, sometimes as low as 1MB, to protect against denial-of-service (DoS) attacks. Without these safeguards, a malicious actor could flood the server with massive requests, quickly exhausting its memory and CPU resources.

Common Scenarios Triggering the Error 413

Pinpointing exactly where and why the error 413 appears is the key to solving it. It’s not just about massive video files; any request with a body that exceeds the server’s configured limit can be a trigger.

To make this tangible, let's look at the most frequent situations that lead to an HTTP 413 error. This table breaks down common scenarios, helping you quickly diagnose the source of your issue.

These examples highlight a critical point: the server rejects the request before your application code (like your PHP script or Node.js app) even gets a chance to see it. This means the solution lies in the server's configuration, not in your application’s logic.

Key Takeaway: The 413 error is a server-side safeguard, not a client-side fault. Your troubleshooting efforts should focus on adjusting server settings to accommodate legitimate large requests without compromising security.

Grasping this concept saves you from hours of debugging the wrong part of your stack. Knowing the server is the gatekeeper directs you straight to the right configuration file, whether that’s for Nginx, Apache, or another layer in your infrastructure.

How to Fix Error 413 in Nginx

If you're running Nginx, you'll be glad to know that fixing a 413 Payload Too Large error is usually straightforward. The problem almost always comes down to a single, powerful directive: client_max_body_size.

This setting defines the maximum size of a client request body that Nginx will process. Out of the box, Nginx sets this to a very cautious 1 megabyte (1M). While this is a smart default for security, it’s often far too restrictive for modern web applications where users upload images, videos, or other large files.

Your job is to find the Nginx configuration file and give that number a sensible bump. It’s a small tweak that makes a huge difference.

Locating and Editing Your Nginx Configuration

First, you need to find your main Nginx configuration file, which is almost always nginx.conf located in the /etc/nginx/ directory on a standard Linux setup. Inside this file, you can adjust the client_max_body_size to a limit that better suits your application's real-world needs.

The key is knowing where to place this directive. Nginx gives you a few options, each with a different scope of influence:

• The http block: Setting it here applies the limit globally to all websites (or server blocks) that your Nginx instance is handling. This is a great "set it and forget it" approach.
• A server block: By adding the directive inside a specific server block, you override the global setting for that one website. This is perfect for when one site has different needs than the others.
• A location block: For the most surgical control, you can place the directive within a location block. This lets you allow large uploads only for a specific part of a site, like /upload, while keeping a stricter limit elsewhere.

This layered approach is one of Nginx's best features, giving you fine-grained control over how your server behaves.

Setting the Right Value

So, what number should you choose? It’s a balancing act. Too low, and your users will keep hitting that 413 error. Too high, and you might open your server up to resource exhaustion attacks from malicious uploads.

For most sites that handle typical user-generated media, a value like 100M is a very practical starting point.

The core idea, echoed by web performance experts, is that the 413 error is a server-side problem that requires a server-side solution. By adjusting directives like client_max_body_size in Nginx, you directly control the payload limits. You can find more on this topic at techcommunity.microsoft.com.

Let's put this into practice. Open /etc/nginx/nginx.conf with your preferred text editor (nano, vim, etc.).

To set a global limit of 100MB, you would add the line inside the http block like so:

http {
    # ... other directives
    client_max_body_size 100M;
    # ... other directives
}

If you only need to adjust this for a single site, you'd edit its specific configuration file, typically found in /etc/nginx/sites-available/your-domain.conf:

server {
    # ... other server directives
    client_max_body_size 100M;
    # ... other directives
}

This flexibility is a big reason why so many of us rely on Nginx. If you're interested in diving deeper, we have a complete guide on configuring Nginx for optimal performance on your VPS.

Applying Your New Configuration

Just saving the configuration file won't do anything yet. You have to tell Nginx to load the new settings. A common mistake here is to just restart the service, which can cause a brief moment of downtime.

A much better approach is to first test your new configuration for any syntax errors. This quick check can save you from taking your server offline with a bad config. Just run:

sudo nginx -t

If you get a success message, you're good to go.

Now, you can apply the changes gracefully without dropping any active user connections. This is done with a simple reload command:

sudo systemctl reload nginx

Nginx will now be using your new client_max_body_size. Just like that, your users can upload larger files, and that frustrating 413 error will be a thing of the past.

Resolving the 413 Error in an Apache Environment

If you're running into an error 413 on an Apache server, the culprit is almost always a single core directive: LimitRequestBody. This is Apache's gatekeeper for incoming data, specifically designed to control the maximum size of an HTTP request body the server will process.

Think of it as the direct counterpart to Nginx's client_max_body_size. Its job is to shield your server from being swamped by excessively large uploads, which could be anything from a legitimate high-resolution video to a malicious denial-of-service attempt. If your users are seeing that 413 message, it's a sure sign the default limit is too restrictive for what your application needs to do.

Where to Make the Change: httpd.conf vs. .htaccess

Before you can increase the limit, you have to decide where to set it. Apache gives you a couple of options, and your choice will depend on the level of access you have and how widely you want the new rule to apply.

• Server-Wide (httpd.conf or apache2.conf): For those with root access, editing the main Apache configuration file is the most straightforward approach. Making a change here sets a new global default for every single site on the server. It’s the go-to method if you manage the whole machine and want a consistent policy across the board.

• Directory-Specific (.htaccess): If you're on shared hosting or just need to adjust the limit for a single application, the .htaccess file is your best friend. Placing the LimitRequestBody directive in a .htaccess file applies the new rule only to that specific directory and any subdirectories beneath it. It’s incredibly useful because it doesn't require server-level permissions.

While .htaccess is wonderfully flexible, just be aware that it comes with a tiny performance trade-off. Apache has to actively look for and read these files in each directory for every request, which can add a slight overhead.

How to Set a Sensible Upload Limit

Now for the important part: choosing the right value. The LimitRequestBody directive takes a number in bytes, ranging from 0 (which means unlimited) all the way up to 2,147,483,647 (2GB).

Setting the limit to 0 might sound like a quick and easy fix, but I’d strongly advise against it. Disabling this limit completely removes a crucial security protection, leaving your server vulnerable.

The real goal is to find a sweet spot. The limit should be large enough to handle your users' biggest legitimate uploads but not so large that it invites trouble. Are you running a forum where users upload profile pictures? 20MB is probably generous. Are you building a platform for video creators? You might need to set it to 250MB or even higher.

Let’s get practical. The value needs to be in bytes, so you’ll need to do a little maths.

To set a 100 megabyte limit, the calculation is 1024 * 1024 * 100, which comes out to 104,857,600. Getting this number right is key to making the configuration work as expected.

Here's how that looks in your configuration file:

LimitRequestBody 104857600

Adding this one line to your .htaccess or httpd.conf file tells Apache to allow uploads up to 100MB, which should immediately solve the error 413 for most common use cases.

Applying Your Changes

Once you've edited your configuration, the final step is to make it live.

If you modified an .htaccess file, you're in luck—the change is typically effective immediately, no restart needed.

However, if you changed the main httpd.conf or apache2.conf file, you'll need to give Apache a full restart to load the new settings. The exact command depends on your server's operating system:

• For modern systems using systemd (like CentOS 7+, Ubuntu 16.04+):
  sudo systemctl restart apache2 or sudo systemctl restart httpd

• For older systems with init.d:
  sudo service apache2 restart or sudo /etc/init.d/httpd restart

After the restart, your new, more generous upload limit will be active. Your users should now be able to upload their larger files without hitting that frustrating 413 wall.

How to Adjust Upload Limits on a Windows IIS Server

If your web stack runs on Windows Server and you hit an error 413, your first stop should be Internet Information Services (IIS). Unlike Linux-based servers where you might be digging through multiple config files in the command line, IIS keeps things a bit more centralised. You’ll find most of what you need right in its graphical interface or within structured configuration files.

The culprit behind a "Payload Too Large" error in IIS is almost always a setting called maxAllowedContentLength. This attribute tells IIS the maximum size of content (in bytes) it should accept in a single request. By default, it's set to 30,000,000 bytes, which comes out to about 28.6MB. That’s often too restrictive for modern web applications that need to handle video files, high-resolution images, or bulky datasets.

Luckily, you have two solid ways to bump up this limit. You can either use the visual IIS Manager for a more guided approach or edit the web.config file directly if you're comfortable with a bit of code.

Using the IIS Manager GUI

For anyone who prefers a visual workflow, the IIS Manager is the most straightforward path. You won't have to touch a single line of code.

Here's how to do it:

• First, launch the Internet Information Services (IIS) Manager. You can find it in the Windows Start menu or under Administrative Tools.
• In the "Connections" pane on the left, find and select the website you're working on.
• In the main panel for your site, locate the "Request Filtering" icon and double-click it.
• Over on the right-hand "Actions" pane, click on "Edit Feature Settings…".
• A dialog box will pop up. Look for the field labelled "Maximum allowed content length (Bytes)" and update the value.

Let's say you want to set a new limit of 100MB. You would enter the value 104857600. Once you click "OK," the change takes effect immediately, and your users should no longer see that pesky 413 error.

Modifying the web.config File Directly

If you're a developer or a sysadmin, you'll probably find that editing the web.config file is much faster. This file sits in your website's root directory and acts as the control panel for its behaviour. This method is also perfect for automated deployments or when you're managing configurations in a Git repository.

To resolve the error 413, you just need to add or update the <requestLimits> section inside <system.webServer>. As many have discovered, adjusting the maxAllowedContentLength is a common fix for this IIS issue, a solution frequently discussed by developers in places like the Dynamics Community forums.

To set that same 100MB limit, you’d add this snippet:

<configuration>
   <system.webServer>
      <security>
         <requestFiltering>
            <requestLimits maxAllowedContentLength="104857600" />
         </requestFiltering>
      </security>
   </system.webServer>
</configuration>

Just drop this into your web.config, save the file, and IIS will apply the new configuration on the fly.

A Quick Tip from Experience: A common pitfall is forgetting that maxAllowedContentLength is measured in bytes, not kilobytes or megabytes. I've seen people accidentally set it to 100 instead of 104857600. Always do the maths (Megabytes * 1024 * 1024) to make sure you're setting the limit you actually want.

Are There Other IIS Settings to Consider?

While maxAllowedContentLength is the main setting you'll need to change, it's worth knowing about another one: uploadReadAheadSize. This attribute defines how many bytes the server reads into a buffer before handing the content off to your application. Its default is a tiny 49,152 bytes (just 48KB).

In some specific cases, like when using client certificate authentication over SSL, a small uploadReadAheadSize can cause connection issues during large uploads because IIS might need to renegotiate the connection mid-stream. If you've already increased maxAllowedContentLength but are still having trouble with uploads over SSL, you might want to try increasing this value, too.

For the vast majority of standard file upload problems, however, just tweaking maxAllowedContentLength is all you'll need to do. If you're looking for more tips on running a Windows server environment smoothly, our comprehensive guide to Windows VPS hosting is a great place to start.

Troubleshooting Beyond the Web Server

So you’ve done everything by the book. You’ve tweaked your Nginx or Apache configs, set generous upload limits, and gracefully reloaded the service. And yet, that frustrating 413 Request Entity Too Large error just won’t go away.

When this happens, it’s a sure sign the problem isn't your web server. The bottleneck is hiding somewhere else in your stack.

Modern web applications are complex systems. It's rarely just a web server talking to a script. You often have application runtimes like PHP, load balancers, and Content Delivery Networks (CDNs) all playing a part. Each of these layers can enforce its own size limits, creating a new, lower ceiling that your requests are hitting.

Digging Into Application-Level Limits

One of the most common culprits, especially if you’re running a CMS like WordPress, Joomla, or Drupal, is the PHP configuration itself. Your web server might be ready to accept a 100 MB file, but if PHP is only configured to handle an 8 MB upload, the request will fail right there.

To fix this, you need to dive into your php.ini file. This is the main control panel for PHP, and two directives are critical:

• upload_max_filesize: This sets the absolute maximum size for a single uploaded file.
• post_max_size: This controls the total size of all POST data in a request. For file uploads to work, this value must be equal to or larger than upload_max_filesize.

Let’s say you want to allow uploads up to 64 MB. You'd find your php.ini file (often located somewhere like /etc/php/[version]/fpm/php.ini) and update the values:

upload_max_filesize = 64M
post_max_size = 64M

After saving the file, don't forget to restart the PHP service to apply the changes (e.g., sudo systemctl restart php8.1-fpm). Sometimes memory can also be a bottleneck; for instance, you might need to fix your WordPress memory limit increase to ensure your application can process larger data loads smoothly.

When Intermediary Services Are the Gatekeeper

If you’ve confirmed that both your web server and application runtime are good to go, it's time to look at the services sitting between your users and your server. Proxies, load balancers, and CDNs are fantastic for performance and security, but they often come with their own default request size limits.

This decision tree infographic provides a great visual for solving a 413 error in an IIS environment, covering both GUI and code-based approaches.

As the flowchart shows, the goal is always the same: find the maxAllowedContentLength setting and increase it to a value that meets your needs.

A classic real-world example is Cloudflare. Millions of sites use its free plan, which imposes a strict 100 MB limit on HTTP POST requests. This means that even if your AvenaCloud VPS is configured to handle 500 MB uploads, Cloudflare will block any request over 100 MB and return that 413 error before it even gets close to your server.

Key Insight: When a 413 error persists after you've configured your server, the problem is almost always an intermediary service. You have to trace the request's entire journey from the user’s browser to your server to find the real bottleneck.

This is where a deep understanding of your infrastructure is non-negotiable. You need to start asking questions:

• Am I using a CDN? Check its documentation for upload limits. With Cloudflare, you'd need to upgrade to an Enterprise plan to request a higher limit.
• Is a load balancer involved? Services like AWS Application Load Balancer (ALB) have their own request body limits that you might need to adjust.
• Is there a reverse proxy in front of everything? If another Nginx or Apache instance is acting as a reverse proxy, its client_max_body_size or LimitRequestBody directive will also need to be increased.

Where to Adjust Upload Limits Across Your Stack

With so many potential points of failure, it helps to have a quick reference. This table shows you where to look for the relevant settings in each layer of a typical web stack.

Knowing which directive controls the limit at each layer is half the battle. Remember to restart the relevant services after making any changes.

Tracing these network paths can feel a bit like detective work. Thinking like a DevOps pro and examining every layer is the key to finally squashing those stubborn 413 errors.

Common Questions About the 413 Error

Once you’ve tweaked your server’s upload limits and gotten things working again, a few other questions usually pop up. Fixing the immediate error 413 is great, but thinking through the bigger picture helps keep your application running smoothly and securely down the road.

Let's dive into some of those common follow-up questions to help you handle specific scenarios and really get a handle on request size limits.

Can I Do Anything About a 413 Error From the Client-Side?

You can’t fix a 413 error from the client-side—that’s purely a server decision. The server is the one saying "no," so only the server can change its mind.

However, you can absolutely prevent the error from ever happening in the first place, which is a lifesaver when you don't have access to the server's configuration. The best approach is to check the file size with JavaScript before the user even hits the upload button. If the file is too big, you can show a friendly message right away. This avoids a frustrating failed request and makes for a much better user experience.

Expert Tip: If your application needs to handle massive files, look into client-side file chunking. This smart technique breaks a large file into smaller, more manageable pieces. Each piece is sent as a separate request, and the server puts them all back together. It’s a clever way to completely sidestep request size limits.

What's a Safe Upload Limit to Set?

Honestly, there's no magic number here. The right limit is all about what your application actually does. Setting an absurdly high limit, like 2GB, might seem easy, but it can open you up to denial-of-service (DoS) attacks where someone tries to cripple your server by flooding it with huge files.

To land on a sensible number, think about these points:

• What do your users need? If you're running a photo-sharing site, maybe 25MB is more than enough. But for a video platform, you might need to allow 500MB or even more.
• What can your server handle? Every large upload eats up memory and disk space while it’s being processed. Be realistic about your server’s resources.
• How's your security posture? A lower limit means a smaller attack surface. It's often smarter to start small (say, 50MB) and only increase it if you find your users genuinely need more.

Why Do I Still Get a 413 Error in WordPress?

This is a classic "gotcha." If you’ve bumped up the limits in Nginx or Apache but WordPress is still throwing a 413 error, the bottleneck is almost certainly PHP itself. WordPress is built on PHP, and PHP has its own set of rules for handling uploads that are completely separate from the web server.

You'll need to look at your php.ini file for two key settings: upload_max_filesize and post_max_size. For an upload to work, the file size has to fit within both of these limits. A good rule of thumb is to make sure post_max_size is always equal to or slightly larger than upload_max_filesize.

Does a Bigger Upload Limit Create a Security Risk?

It can, yes. If you're not careful, a high upload limit can introduce some security headaches. The biggest one, as we touched on, is resource exhaustion. A bad actor could deliberately send massive files to hog your server's bandwidth, CPU, and memory, slowing your site to a crawl or even crashing it.

To keep things safe, you should put a few safeguards in place:

• Authenticate first: Only let logged-in, trusted users upload large files.
• Validate file types: Be strict about what kinds of files you accept. Don't let users upload executable scripts or other potentially harmful content.
• Monitor your resources: Keep an eye on your server's performance. Tools that watch for sudden spikes in resource usage can give you an early warning of an attack.

By finding the right balance between what your users need and what keeps your server safe, you can confidently manage upload limits without letting the error 413 get in your way.

Ready to build on a platform that gives you full control over your server environment? AvenaCloud offers powerful and scalable VPS solutions, allowing you to easily configure Nginx, Apache, and PHP settings to prevent errors like 413. Get started today and experience hosting without limits at https://avenacloud.com.