How to Increase PHP Memory Limit Without Breaking Your Website

Last year I upped my PHP memory limit from 256M to 2G because a plugin kept throwing “allowed memory size exhausted” errors, and I figured more is just better, right? Wrong. The site got slower under load and my host flagged the account for excessive resource usage within a week. If you’re trying to figure out how to increase PHP memory limit the right way instead of just cranking the number until errors stop, this is the actual process, including the part where doing it wrong causes new problems.

The error itself is simple enough — PHP ran out of the memory it’s allowed to use and killed the script. But where you fix that, and how much you bump it by, depends on your hosting setup, and there are at least four different places this setting can live, which is exactly why people end up editing the wrong file and wondering why nothing changed.

Quick Answer

• Find your current limit first: create a phpinfo() file or check via WP admin (if WordPress) before changing anything blind
• Shared hosting: usually set via php.ini in cPanel, a .user.ini file, or your host’s control panel — not always editable directly
• WordPress-specific: can be raised in wp-config.php, but this only works if your host’s server-level limit is already higher
• Common safe values: 256M for most sites, 512M if running heavy plugins or e-commerce, rarely need more than that
• Server-level limit always wins — if PHP.ini caps you at 128M, your wp-config.php setting of 512M does nothing

Why the Error Happens (And Why “Just Increase It” Isn’t Always Right)

There are a few genuinely different causes bundled under the same “memory exhausted” error, and they don’t all have the same fix.

A poorly optimized plugin or theme is leaking memory. This is more common than people want to admit. Some plugins load huge datasets into memory unnecessarily, or don’t release memory properly between operations. If you just increase the limit without addressing this, you’re masking the real problem — the site works today but the plugin’s memory usage will keep growing as your content or user base grows, and you’ll be back here in six months bumping the limit again.

Large image processing or file uploads. WooCommerce sites regenerating thumbnails, or anyone running bulk media imports, can spike memory usage well past normal browsing traffic. This is a legitimate case for a higher limit, at least temporarily during the operation.

Server-level restrictions that override your application settings. So this is the one that trips people up constantly — you can set memory_limit = 512M in wp-config.php all day, but if your hosting account’s actual php.ini or the server’s global config caps PHP at 128M, your setting gets silently ignored. No error telling you this happened. It just doesn’t work, and you assume your fix failed for some other reason.

And there’s a less obvious one: badly configured caching plugins that hold everything in memory rather than writing to disk properly. I’ve seen this cause memory errors that looked identical to a plugin conflict but were actually a caching config issue entirely.

Where PHP Memory Limits Live (And Why This Gets Confusing)

That “Overrides” column is really the whole story here. If you edit wp-config.php and nothing changes, it’s very likely because something higher up the chain is capping you first. This is the single most common reason people say “I increased the limit and it didn’t work.”

Step-by-Step: Increasing PHP Memory Limit

Step 1: Check your current limit before touching anything. In WordPress, go to Tools > Site Health > Info, and look under Server for “PHP memory limit.” Not running WordPress? Create a file called info.php with <?php phpinfo(); ?>, upload it, visit it in browser, search for “memory_limit,” then delete the file immediately after (leaving phpinfo() files sitting on a live server is a real security issue, don’t skip the deletion).

Step 2: Check if your host uses cPanel with MultiPHP INI Editor. This is the cleanest option if it’s available — a dropdown to pick your domain, a field for memory_limit, done. No file editing needed. Look for “MultiPHP INI Editor” or “Select PHP Version” in cPanel.

Step 3: If no panel option, try wp-config.php (WordPress sites). Add this line near the top, before the “That’s all, stop editing” comment:

define('WP_MEMORY_LIMIT', '256M');

This only raises WordPress’s own internal limit, and only up to whatever your server allows. It won’t override a lower server cap.

Step 4: Try .user.ini if wp-config.php didn’t work. Create or edit a .user.ini file in your site’s root directory with:

memory_limit = 256M

This works on most PHP-FPM setups but takes a few minutes to apply since PHP caches these files. Don’t panic if it’s not instant.

Step 5: Try .htaccess as a last resort (Apache only).

php_value memory_limit 256M

This one’s finicky — if your host runs PHP as a module rather than FPM/CGI, this can actually crash your site with a 500 error instead of just failing quietly. Worth knowing before you try it.

Step 6: If nothing works, contact your host directly. Some shared hosting plans hard-cap memory limits regardless of what you configure client-side, as a resource protection measure. At that point it’s either a plan upgrade or a different host, not a config fix.

What Actually Worked For Me

Okay so this one actually took a few tries, which was annoying because I assumed it’d be quick. I started with wp-config.php, set WP_MEMORY_LIMIT to 512M, refreshed the site — same error, no change at all. Figured I’d made a typo, checked it three times, nope, syntax was fine.

Turned out my host’s server-level php.ini was capping everything at 128M regardless of what WordPress asked for, and there was no cPanel option visible to change it myself — the MultiPHP INI Editor was there but greyed out for memory_limit specifically, which I hadn’t seen before and initially assumed was a bug on my end. Opened a support ticket, and the tech mentioned almost as an aside that memory_limit changes on their shared plans need to go through them directly for “resource management reasons.” Which, fine, I guess, but that would’ve been useful information literally anywhere in their documentation.

They bumped it server-side to 256M, the error disappeared immediately, and I never did figure out why that one setting specifically was locked while everything else in the panel was editable. Your mileage may vary depending on host — some don’t lock this at all.

Advanced Fixes and Edge Cases

Check for memory leaks via error logs before just raising the limit. If you have access to PHP error logs (often under cPanel’s “Errors” section, or via SSH at a path like /home/username/logs/), search for repeated memory exhaustion at the same file/line across multiple requests. That pattern points to a specific plugin or script, not a general “site needs more memory” situation.

PHP-FPM pool settings can override everything else. If you’re on a VPS running your own PHP-FPM, check the pool config file (usually under /etc/php/[version]/fpm/pool.d/) for a php_admin_value[memory_limit] line — this one can’t be overridden by wp-config.php or .htaccess at all, by design, since it’s meant as a hard admin-level cap.

Memory limit isn’t the same as memory usage under load. So this is where it gets a little more complicated — a single PHP process might run fine at 256M, but if you’ve got 20 concurrent PHP-FPM workers each potentially hitting that ceiling during a traffic spike, your server’s actual RAM needs to support 20x that number, not just the per-process limit. This is where “I increased memory_limit and now my whole server is slow” comes from — you fixed the per-script error and created a server capacity problem instead.

OPcache and memory_limit interact in ways that aren’t obvious. Not something I fully understand the internals of, but from what I’ve seen, poorly tuned OPcache settings can make memory pressure worse even when memory_limit itself looks fine on paper. If you’re deep in a persistent memory issue after raising the limit, OPcache config is worth a look before assuming you need to raise the limit again.

Prevention Tips

• Set memory_limit based on actual need, not a round number that “feels safe” — 512M for a normal WordPress site is usually overkill
• Audit plugins periodically; memory leaks tend to come from the same handful of poorly maintained ones
• Don’t raise memory_limit as a permanent fix for a temporary operation like a one-time bulk import — lower it back after
• Keep an eye on your hosting resource usage dashboard if your host provides one; memory spikes often show up there before they show up as errors

FAQ

What’s a safe PHP memory limit for WordPress? 256M covers most sites fine. E-commerce or membership sites with heavy plugins sometimes need 512M. Going straight to 1G or 2G because you saw it recommended somewhere usually just delays the real fix.

Why did increasing memory_limit in wp-config.php do nothing? Your server-level php.ini is probably capping it lower, and that setting always wins over what WordPress asks for.

Can too high a memory limit cause problems? Yes — a runaway or looping script can consume way more server resources before it eventually fails, and on shared hosting this can get your account flagged or throttled.

Do I need to restart PHP after changing memory_limit? Depends on the method. php.ini and pool config changes usually need a PHP-FPM restart. wp-config.php and .htaccess changes apply immediately on next page load.

Is this different for WooCommerce specifically? Not fundamentally, but WooCommerce sites hit memory limits more often due to product data processing, so they more frequently need the higher end of the safe range.

Editor’s Opinion

dont just set this to some huge number and move on, thats how you end up with a resource usage warning email from your host a week later. figure out if its an actual plugin problem first, check the error logs if you can, and only raise the limit as much as you actually need. also if your changes arent doing anything at all theres a decent chance somethings capping you higher up the chain and no amount of editing wp-config is gonna fix that