Your Hosting File Manager Upload Limit Is a Joke — Here’s How to Actually Fix It

What the File Manager Upload Limit Actually Is

Before you can fix the problem, it helps to understand exactly what’s causing it. The “upload limit” you’re hitting isn’t a single setting — it’s the product of several PHP configuration directives working in concert. When any one of them is set below what your file requires, the upload fails. When multiple are set low, you can hit the wall even faster than you’d expect.

The three PHP settings most directly responsible are upload_max_filesize, post_max_size, and memory_limit.

upload_max_filesize

This is the most obvious one. It’s the raw cap on how large a single uploaded file can be. If it’s set to 8M, you cannot upload any file larger than 8 megabytes through a PHP-powered interface — including your hosting control panel’s file manager, WordPress’s media uploader, and WordPress’s plugin/theme installer. Full stop. The server rejects anything that exceeds this value before it’s even processed.

post_max_size

This one trips people up. Even if upload_max_filesize is set generously, post_max_size can still kill your upload. This setting controls the maximum size of an entire HTTP POST request — which is how file uploads are transmitted. Since a file upload is sent as part of a POST request, post_max_size must be equal to or larger than upload_max_filesize. If it’s smaller, uploads above the post limit will silently fail, often with confusing error messages that don’t clearly explain what went wrong.

memory_limit

Memory limit is the often-overlooked third variable. PHP needs to load the uploaded file into memory temporarily to process it. If your memory_limit is 64M and your file is 60MB, you might slip through on filesize alone — but PHP will run out of memory during processing and the whole thing falls apart. A generous upload limit paired with a stingy memory limit still equals a broken upload experience.

max_execution_time and max_input_time

For larger files, two more settings come into play: max_execution_time (how long a PHP script is allowed to run) and max_input_time (how long PHP waits to receive input before giving up). A very large upload on a slow connection can exceed these time limits even if the filesize itself is acceptable, causing the upload to time out before it completes.

The cPanel file manager, Plesk’s file manager, DirectAdmin’s, and every other control panel’s equivalent all operate through PHP on the backend. That means they’re bound by these exact same PHP settings. There’s no magic override just because you’re using your host’s official tool. If PHP says 8MB is the limit, the file manager says 8MB is the limit.

Why Hosts Set It So Aggressively Low

The obvious question, once you understand the mechanics, is: why? Why would a company whose entire business model depends on hosting websites cripple something as basic as file uploads? The answer is a mix of server architecture decisions, shared resource management, and — honestly — laziness about updating defaults.

Shared Hosting Resource Pools

On shared hosting, hundreds or thousands of accounts share the same physical server. A single account that uploads a massive file and triggers intensive PHP processing can slow down every other account on that machine. By capping upload sizes, hosts limit the worst-case resource spike any single account can cause. This is a legitimate concern — to a point. The problem is that hosts often set these limits based on assumptions from fifteen years ago and never revisit them. A 2MB limit made more sense when the average WordPress plugin was 500KB. Today, a single premium plugin can easily run 20-40MB.

Outdated PHP Default Inheritance

PHP’s built-in defaults are conservative for good reason — they’re global defaults that apply everywhere from tiny shared servers to enterprise infrastructure. The default upload_max_filesize is 2MB. The default post_max_size is 8MB. Many shared hosts never customize these at the server level, so customers inherit PHP’s own conservative defaults without the host making a deliberate choice. It’s negligence dressed up as caution.

Upsell Incentive

Let’s be blunt: some hosts keep upload limits low as soft leverage toward plan upgrades. When you can’t upload a plugin and call support, the answer is often “our Business plan gives you full control.” The restriction itself becomes a sales funnel. It’s cynical, but it’s real.

Security Theater

Low upload limits are sometimes framed as a security feature — if someone compromises your credentials, they can’t upload large malicious files. There’s a kernel of truth, but it’s wildly overstated. PHP shells that enable full server compromise are often just a few kilobytes. This framing is mostly rationalization, not genuine security posture.

The irony of a low upload limit is that it stops legitimate site owners from doing legitimate work while doing essentially nothing to stop bad actors who already have server access. — Observed in approximately every hosting forum thread about this topic, ever

The Real Cost of a Tiny Upload Limit

This isn’t just an inconvenience. A chronically low upload limit actively damages your ability to manage your WordPress site effectively — and the damage compounds over time in ways that aren’t always immediately obvious.

Plugin and Theme Installation Breaks Down

The most immediate pain point: you can’t install plugins or themes from ZIP files through the WordPress admin dashboard. WordPress’s built-in installer uses the same PHP upload machinery, so the same limits apply. When you’ve purchased a premium plugin and downloaded the ZIP, or when you’ve built a custom child theme, or when you’re trying to deploy a site from a backup — all of these require uploading ZIP files that routinely exceed 8MB or even 20MB. A low upload limit makes WordPress’s most basic administrative functionality unreliable.

Media Library Limitations

High-resolution photography, video clips, audio files, large PDFs — all of these are increasingly common content types, and all of them routinely exceed a 2MB or 8MB upload limit. If you’re running a photography portfolio, a podcast site, or any content-heavy publication, a stingy upload limit effectively forces you to use external hosting for your media — adding complexity, potential link rot, and ongoing cost to your operation.

Backup and Migration Nightmares

Site migration is already a stressful process. When your destination host has a restrictive file manager, importing a database export or uploading a backup archive becomes a manual multi-step ordeal involving FTP clients or SSH commands. What should be a 15-minute task becomes a half-day project.

Developer Workflow Disruption

For developers managing client sites, a low upload limit on a client’s shared host is a recurring friction point. You can’t quickly push a plugin update, upload a new theme version, or deploy assets. You end up doing gymnastics around a restriction that has no business being there in the first place.

How to Diagnose Your Exact Limits

Before you start changing settings, you need to know exactly what limits you’re working with. Guessing wastes time. There are a few reliable ways to find out precisely what PHP is doing on your server.

WordPress’s Built-In Indication

Navigate to Media > Add New in your WordPress admin. WordPress reads your PHP settings and displays “Maximum upload file size: X MB” at the bottom of the upload area. This is the most accessible check, though it only shows you upload_max_filesize — it doesn’t show you post_max_size or memory_limit, which might be lower.

Create a phpinfo() File

The most comprehensive method: create a temporary PHP file in your public root directory — name it something hard to guess, like serverinfo_temp.php — containing only phpinfo(); between opening and closing PHP tags. Access it in your browser for a full readout of every PHP setting. Search for “upload_max_filesize,” “post_max_size,” and “memory_limit” to see your actual values. Delete this file immediately afterward — leaving phpinfo() files accessible is a security exposure.

WP-CLI and Plugin-Based Checks

If you have SSH access and WP-CLI installed, running php -i | grep upload from the command line gives you clean, readable output of your PHP configuration — fast and without creating temporary files. If you’re not comfortable with the command line, several free WordPress plugins (like “PHP Info” or “WP Server Info”) display PHP configuration in a readable format. Install one, read your limits, uninstall it.

Fix Method 1: Edit php.ini

The php.ini file is the master configuration file for PHP on your server. Editing it is the most direct and reliable way to change your upload limits. Whether you can do this depends on your hosting environment and your plan level.

Finding php.ini on Shared Hosting

On cPanel shared hosting, there are a few places php.ini might live. It could be in your home directory, in the public_html directory, or in the directory where the specific site lives. The easiest approach: use your file manager to search for “php.ini” starting from your home directory. If you find one, open it.

If you don’t find one, you may need to create one. On many cPanel servers, PHP looks for a php.ini file in the directory where a script is running. Creating a php.ini in your public_html root will affect the entire site hosted there.

What to Add or Change

Once you have your php.ini file open, locate these directives and update them (or add them if they don’t exist):

• upload_max_filesize = 128M
• post_max_size = 128M
• memory_limit = 256M
• max_execution_time = 300
• max_input_time = 300

128MB is a reasonable target for upload size. It’s large enough to handle virtually any plugin, theme, or media file you’d normally upload through a browser interface, without being so large that it causes resource contention issues on shared hosting. Memory at 256MB gives PHP room to actually process those uploads. The time limits at 300 seconds (5 minutes) accommodate large uploads on slower connections.

Important: Server-Level Overrides

Here’s the part that frustrates many people: even with a perfectly configured php.ini, if your hosting company has set server-level limits in their main php.ini or in php-fpm pool configuration, your directory-level php.ini might be ignored for certain settings. If you edit your php.ini, save it, verify it with a phpinfo() call, and the values still show the old limits — you’re running into server-level overrides that you can’t change without either SSH root access or a conversation with support.

Fix Method 2: The .htaccess Approach

If you’re running on an Apache web server (most shared hosting still is), you can often override PHP settings through your .htaccess file — the same file where you put WordPress’s permalink rules. This works on servers where PHP runs as an Apache module (mod_php). It doesn’t work on servers using PHP-FPM with Nginx, or on configurations where AllowOverride is set to None.

What to Add to .htaccess

Open your .htaccess file in the root of your WordPress installation. You’ll find the existing WordPress rules that look something like the standard WordPress permalink block. Above or below those rules (not inside them), add these lines:

• php_value upload_max_filesize 128M
• php_value post_max_size 128M
• php_value memory_limit 256M
• php_value max_execution_time 300
• php_value max_input_time 300

Save the file and test an upload. If the server supports this method, you’ll see the values change in a fresh phpinfo() read.

Why This Sometimes Fails

The .htaccess method only works when PHP is running as an Apache module — the traditional mod_php setup. Modern hosting is increasingly moving to PHP-FPM, where PHP runs as a separate process and doesn’t read Apache directives. If you’re on Nginx (LiteSpeed can also behave differently here), .htaccess PHP directives simply don’t apply. Many hosts have also explicitly disabled php_value overrides in .htaccess for security or resource management reasons, in which case the directives will be silently ignored — or worse, they’ll cause a 500 Internal Server Error.

If adding these lines breaks your site (500 error), remove them immediately. Your server doesn’t support this method.

Fix Method 3: wp-config.php for WordPress Specifically

WordPress has its own mechanism for setting some configuration values, and one of them is a constant that affects the upload limit as WordPress reports it and enforces it. This method doesn’t change PHP’s actual hard limits — it can only raise the WordPress-reported limit up to whatever PHP’s actual limit already allows — but it’s still useful for a specific scenario.

Adding WP_MEMORY_LIMIT

In your wp-config.php file, before the line that says “That’s all, stop editing,” add:

• define(‘WP_MEMORY_LIMIT’, ‘256M’);
• define(‘WP_MAX_MEMORY_LIMIT’, ‘512M’);

This tells WordPress to request up to 256MB for regular operations and 512MB for admin-side operations. If PHP’s memory_limit is already higher than what WordPress was using, this gives WordPress permission to use more of what’s available.

The Limitation You Must Understand

WordPress cannot grant itself more than PHP allows. If PHP’s upload_max_filesize is 8MB, no WordPress constant will let you upload a 50MB file. This method works when the bottleneck is WordPress’s own conservative requests to PHP, not PHP’s hard limits. It’s a complement to the other methods, not a replacement.

Fix Method 4: Just Ask Your Host

This sounds obvious. It isn’t always the first thing people try, because the assumption is that the host will say no or push you toward an upgrade. Sometimes that assumption is correct. Often, it isn’t.

Many shared hosts will increase your PHP limits if you simply open a support ticket and ask clearly. The magic phrase is something like: “I need my upload_max_filesize, post_max_size, and memory_limit increased to at least 128MB. Can you do this for my account?” Be specific. Ask for the exact values you need. Don’t say “can I upload bigger files?” — that’s vague and invites vague answers.

What to Expect

Some hosts will do this within minutes, no questions asked. Others will say it requires an upgrade. Others will send you to documentation that explains the self-service methods (php.ini, .htaccess) that you’ve already tried. A small number of hosts have genuinely hard limits baked into their infrastructure that cannot be changed at the individual account level.

If your host says they can’t change it and there’s no path forward on your current plan, that’s important information. It tells you something concrete about whether this host is a good long-term home for a site that needs to be actively managed.

A hosting company that won’t let you upload a plugin without a fight is a hosting company that’s already telling you something about how the rest of the relationship will go. — Perspective earned from too many support tickets

Fix Method 5: WP-CLI and SSH

If you have SSH access to your server — which is increasingly common even on mid-tier shared plans, and standard on VPS and dedicated options — WP-CLI opens up a cleaner path to installing plugins and themes without touching the upload limit at all.

Installing Plugins via WP-CLI

WP-CLI is the command-line interface for WordPress. From an SSH terminal, navigate to your WordPress installation directory and run:

• wp plugin install /path/to/your/plugin.zip –activate

This bypasses the browser-based file upload entirely. WP-CLI reads the ZIP directly from the filesystem and installs it through WordPress’s own plugin installation functions — without any of the PHP upload limit constraints that affect browser uploads. There is no upload happening; it’s a local file operation from the server’s perspective.

You can also install plugins directly from the WordPress.org repository by slug (wp plugin install woocommerce –activate), update plugins in bulk, switch themes, and activate or deactivate plugins — all without touching the upload system. WP-CLI is one of the most powerful tools in a WordPress manager’s toolkit, and bypassing upload limit headaches is just one of many reasons to learn it.

First Upload the ZIP via FTP or SCP

The WP-CLI method assumes the file is already on the server. If you have a premium plugin ZIP on your local machine, you’ll need to get it to the server first — via FTP, SFTP, or SCP from the command line. Once it’s on the server, WP-CLI can handle the rest. This two-step process is sometimes less convenient than a direct browser upload, but it’s reliable and completely immune to PHP’s upload limits.

Fix Method 6: Use FTP/SFTP Instead

Here’s the method that most hosting documentation eventually points you toward — and while it can feel like a step backward from the convenience of a browser-based file manager, it completely sidesteps the PHP upload limit problem. FTP and SFTP operate at a completely different layer than PHP. They’re direct file transfer protocols that talk to an FTP daemon on your server, not to a PHP script. PHP’s upload limits don’t apply.

Getting an FTP Client

FileZilla is the standard recommendation — free, cross-platform, actively maintained, and handles SFTP without plugins. WinSCP is a strong Windows-only alternative; Cyberduck is popular on macOS. All allow you to connect using FTP credentials from your hosting control panel and transfer files of essentially any size, limited only by your disk quota.

FTP for WordPress Plugin/Theme Installation

Installing a plugin via FTP when the WordPress admin dashboard is blocked works like this: extract your plugin ZIP locally, connect via FTP, and upload the extracted plugin folder to /wp-content/plugins/ on your server. WordPress will recognize it as an installed plugin, ready to activate. The same approach works for themes: extract, upload to /wp-content/themes/, activate from Appearance > Themes. A few extra steps — but completely reliable on any host regardless of upload limits.

Security Note on FTP vs SFTP

Plain FTP transmits credentials in cleartext — a genuine security concern. SFTP (SSH File Transfer Protocol) encrypts everything and runs over SSH. Whenever your host offers SFTP — and most do — use it instead of plain FTP. Setup is virtually identical in FileZilla and most FTP clients.

Fix Method 7: Manual Plugin Installation via File Manager

Your hosting control panel’s file manager has an upload limit — but it also has the ability to extract ZIP files that are already on the server. You can sometimes combine these to get around the upload size restriction entirely.

The Split-and-Upload Approach

Some file managers let you upload multiple smaller files without restriction even if a single large file is blocked. If your plugin ZIP is 25MB but your limit is 8MB, you’re stuck on a direct upload. But: if you can get the ZIP onto the server in segments using another method (like uploading a self-extracting archive in chunks, or uploading directly via SFTP and then using the file manager’s extract function), you can sometimes work around the limit without a full FTP client setup.

Extract ZIP Functionality

Most cPanel, Plesk, and DirectAdmin file managers have a right-click “Extract” option for ZIP files. If you can get your ZIP to the server via any method — FTP, SCP, or the file manager itself if the file is small enough — the extract function can deploy it to the right location without any upload size concerns. This is especially useful when the bottleneck is the browser upload specifically, not the server’s overall file handling capability.

Which Hosts Actually Give You Reasonable Limits

Enough about workarounds. Let’s talk about hosts — because the cleanest solution to an upload limit problem is being on a host that doesn’t have one in the first place, or that makes it trivially easy to adjust.

Managed WordPress Hosts

Managed WordPress hosting tends to come with much more sensible upload limits out of the box. Kinsta, for example, runs on Google Cloud infrastructure and provides PHP configurations optimized for WordPress, including upload limits that won’t block you from installing normal plugins. Their hosting environment is engineered specifically for WordPress workloads, which means the defaults reflect what WordPress actually needs rather than what a generic PHP application from 2005 needed.

Hosts That Get It Right

InterServer is one of the more underrated options in shared hosting. Their standard shared plans allow php.ini customization through cPanel, and their support team is responsive to limit increase requests without pushing upgrades as the first answer. For budget-conscious site operators who need real control, InterServer is worth serious consideration.

KnownHost takes a different approach — their managed VPS options come with root access or access to a managed control panel where PHP limits are genuinely configurable. If you’re managing multiple WordPress sites or need reliable upload functionality, their managed VPS environment eliminates the entire upload limit problem by giving you genuine server control.

Cloudways sits in an interesting category: managed cloud hosting that gives you access to PHP configuration settings through a clean dashboard interface. You can set upload_max_filesize, post_max_size, and memory_limit directly through their application management panel without touching the command line. For developers or serious site owners who want cloud performance without full server administration, this is a compelling middle ground.

SiteGround has its own custom control panel (replacing cPanel after the cPanel pricing explosion) and includes a PHP settings management tool that lets you change upload limits directly from the interface. No ticket required, no manual file editing. It’s one of the few shared hosts where this problem is genuinely self-service.

UltaHost offers managed WordPress hosting with server configurations preset for WordPress performance, including PHP limits that reflect actual WordPress requirements rather than legacy defaults. JetHost is a newer entrant worth watching — their managed plans come with PHP configuration access that puts the kind of upload limit control you need within reach without escalating to support every time.

Hosts That Make It Harder Than It Should Be

Budget shared hosts tend to be the worst offenders for low, non-configurable upload limits. When a host’s business model depends on fitting the maximum number of accounts onto the fewest servers, conservative resource limits become a feature of the model, not an oversight. When the answer to every configuration question is “upgrade,” that’s a host optimizing for upsells over customer success.

Bluehost and HostGator are the big-brand examples — both widely advertised, both running on infrastructure that makes PHP configuration more complicated than it needs to be on lower-tier plans. Fixing upload limits typically requires either a support ticket or manual php.ini editing, whereas developer-focused hosts make this self-service. IONOS varies significantly by plan tier — PHP customization is available higher up, but entry-level plans are more restricted.

What to Look For When Choosing a Host

If you’re shopping for hosting and this issue matters to you — and it should, because it affects everyone who manages WordPress sites — here are the specific questions and evaluation criteria that actually predict whether you’ll have upload limit problems.

Ask Before You Buy

Don’t assume. Ask the sales or pre-sales team explicitly: “What is the default upload_max_filesize on your shared plans?” and “Can I change PHP settings myself through the control panel?” Their answer tells you a lot. A host that knows the answer immediately and can point you to a documentation page for self-service PHP configuration is a host that’s thought about this. A host that’s vague, deflects to “our plans are fully featured,” or points you to a generic FAQ is a host that probably hasn’t prioritized this.

Look for Self-Service PHP Management

The gold standard is a hosting control panel that lets you change PHP settings through a GUI without editing files. SiteGround’s tool, Cloudways’s application settings panel, and Kinsta’s PHP settings interface are examples. When a host provides this, it signals that they respect your autonomy as a site manager and have thought about what developers and site owners actually need.

SSH Access Is a Proxy for Real Control

Hosts that provide SSH access on standard plans tend to be more technically serious in general. SSH access means you can use WP-CLI, run phpinfo checks, manage files via SFTP, and operate without depending on a browser interface for everything. It’s a reliable signal that the host isn’t trying to wrap you in a padded room.

Read Community Reviews on Specific Issues

WordPress.org forums, r/wordpress, and hosting-specific subreddits contain real user experience reports about upload limits and PHP configuration flexibility. Search for your target host name alongside “upload limit,” “php.ini,” or “increase memory limit” and see what actual users have reported. These are more reliable indicators than any host’s marketing materials.

The Plugin ZIP Problem Specifically

We’ve talked about the general upload limit problem, but the plugin ZIP scenario deserves its own focused attention because it’s the situation that most commonly drives people to search for solutions — and because it has some unique wrinkles.

Why Plugin ZIPs Are Getting Larger

Modern WordPress plugins are genuinely larger than they used to be, for legitimate reasons. Page builders like Elementor and Divi bundle JavaScript libraries, icon sets, font files, and template libraries. A modern page builder can easily run 25-50MB compressed. Security plugins bundle threat databases. Backup plugins include their own dependencies. Premium plugins from commercial developers often include demo content, documentation, and bundled add-ons. The days of a plugin being a single PHP file are long gone — and yet, many hosts’ upload limits were set during exactly that era and have never been revisited.

The WordPress Plugin Installer vs. Direct Upload

WordPress’s built-in plugin installer (Plugins > Add New > Upload Plugin) uses the same PHP upload mechanism as everything else. The limit you hit in the file manager is the same limit you’ll hit in the WordPress admin plugin installer. They’re both going through PHP, they’re both bound by the same upload_max_filesize.

The one difference: WordPress’s installer might show you a slightly more helpful error message. “The uploaded file exceeds the upload_max_filesize directive in php.ini” is at least specific about the cause, even if it doesn’t tell you how to fix it.

The “Broken Plugin” Confusion

When a plugin upload fails partway through due to a timeout, WordPress can end up with a partially extracted plugin directory. This causes confusing errors — sometimes a “plugin already installed” message, sometimes a broken entry in the plugins list. If this happens, connect via FTP and manually delete any partial plugin directory in /wp-content/plugins/ that matches your plugin’s name, then reinstall via FTP from scratch.

Large Premium Plugins and ZIP Sources

Some premium plugin developers split their distributions. A plugin you purchase might include a lightweight “code only” ZIP plus a separate content package or add-on bundle. If you’re hitting an upload limit on a major commercial plugin, check whether their download portal offers a smaller initial upload. Not all do, but it’s worth checking before you spend an hour on workarounds.

The Bigger Picture: Server Configuration Philosophy

The upload limit problem is a symptom of a broader issue in the web hosting industry: the persistence of configurations that made sense ten or fifteen years ago, baked into infrastructure that never gets updated.

The “Sensible Defaults” Problem

PHP’s defaults are set for a generic environment that prioritizes safety and minimal resource usage — appropriate for a runtime deployed anywhere from a Raspberry Pi to a data center. But shared hosting providers aren’t deploying generic PHP environments. They’re deploying WordPress environments, predominantly. And WordPress has well-documented requirements that don’t match PHP’s generic defaults.

WordPress recommends a memory limit of at least 256MB and explicitly states that the 32MB default is insufficient for many plugins and themes. Hosts that have read and acted on this guidance set their defaults accordingly. Hosts that haven’t are running on inertia from a decade ago.

The VPS Inflection Point

There’s a meaningful line between shared hosting and a virtual private server (VPS): root access. On a VPS, you edit the main php.ini directly. You configure PHP-FPM pools. You set memory limits. You control everything without workarounds, support tickets, or waiting. The upload limit becomes entirely your own decision.

The cost gap between shared hosting and a managed VPS has narrowed considerably. Providers like KnownHost and Cloudways offer managed VPS products at price points that aren’t dramatically more expensive than premium shared hosting — and the operational difference in what you can configure is enormous. If you’ve run into upload limit problems more than once, the math of a managed VPS starts to make real sense.

PHP-FPM and the Modern Hosting Stack

Modern hosting increasingly runs PHP-FPM — a FastCGI Process Manager that runs PHP as a separate service rather than as an Apache module. PHP-FPM is faster and more efficient than mod_php, and it’s become the standard on both VPS environments and modern shared hosting stacks. The relevant note: PHP-FPM’s configuration lives in pool configuration files, not in .htaccess-readable directives. This is part of why the .htaccess method doesn’t work on modern hosts — they’ve moved past the architecture where that method was relevant. Fixing upload limits on a PHP-FPM server requires either direct access to those pool configuration files (root access), or a host-provided GUI tool that modifies them on your behalf. The hosts that have built that kind of tool are the ones that have actually thought about what their customers need.

The Future: Containerization

WordPress hosting is increasingly moving toward containerized environments where each site runs in its own isolated container with its own PHP configuration. In this model, upload limits are genuinely per-site and per-customer, without the shared-server resource pooling concerns that justified conservative defaults in the first place. Kinsta runs this way on Google Cloud, and the architecture is spreading. As it does, the technical justifications for restricting upload sizes on behalf of neighboring accounts disappear. What remains is a pure policy decision — and hosts that choose permissive settings win on developer experience, every time.