How to Increase PHP Memory Limit & Fix Memory Errors

A fatal error: allowed memory size of 134217728 bytes exhausted message means a single PHP process asked for more RAM than the server was willing to hand it, and PHP killed the request rather than let it run away. The quick fix is to increase the PHP memory limit from the usual 128M to 256M or 512M in wp-config.php, php.ini or your hosting dashboard. The longer fix is finding whatever plugin, import or image job burned through that memory in the first place.

Those numbers in the error are bytes: 134217728 is 128M, 268435456 is 256M, and 536870912 is 512M. Knowing which one you hit tells you how far your current ceiling already sits above PHP’s defaults.

What “Allowed Memory Size Exhausted” Actually Means

PHP caps how much memory any one script can allocate through the memory_limit directive, which ships with a default of 128M in modern builds according to the official PHP manual. The cap is per process, not per site, so twenty visitors can each use 128M at the same time. When a script crosses the line, PHP throws a fatal error and the page dies, often as a white screen or a half-rendered admin panel.

WordPress layers two more constants on top of the server value. WP_MEMORY_LIMIT defaults to 40M on single sites and 64M on multisite, while WP_MAX_MEMORY_LIMIT raises the ceiling to 256M for admin screens and cron jobs. Neither constant can exceed what the server allows, which is why editing only wp-config sometimes changes nothing at all.

Check Your Current Limit Before You Change Anything

Guessing wastes time. There are three reliable ways to read the active value in under a minute:

Site Health: in wp-admin, go to Tools, Site Health, Info, then open the Server panel and read the PHP memory limit row.
A phpinfo file: upload a file containing <?php phpinfo();, load it in a browser, search for memory_limit, then delete the file immediately.
WP-CLI: run wp eval 'echo ini_get("memory_limit");' over SSH, which also shows the CLI value, often different from the web one.

Note both the local and master values in phpinfo. If local reads 256M and the error still quotes 128M, something is overriding your setting further down the chain.

Four Places to Increase the PHP Memory Limit

Start at the top of this list and stop as soon as the value changes. Each method targets a different layer, and stacking all four tends to create conflicts that are miserable to debug later.

wp-config.php: above the “stop editing” comment, add define('WP_MEMORY_LIMIT', '256M'); and define('WP_MAX_MEMORY_LIMIT', '512M');. The WordPress developer documentation covers the exact placement.
php.ini: set memory_limit = 256M. On most cPanel or managed platforms you’ll find this under a PHP settings editor rather than a raw file, and the change applies after a PHP-FPM reload.
.htaccess: add php_value memory_limit 256M. This only works on Apache with mod_php, and it throws a 500 error on LiteSpeed or Nginx setups running PHP-FPM.
Hosting control panel: managed hosts expose the value as a dropdown. We set it per account on our WordPress PHP hosting stack so nothing in the file system can be silently overwritten by an update.

After each change, reload the page that failed and recheck Site Health. If the number didn’t move, the layer above you is winning.

We cover this topic in more depth in Troubleshooting the "Briefly Unavailable for Scheduled Maintenance" Error.

We cover this topic in more depth in How to Fix WordPress Image Upload HTTP Errors.

Why Your New Limit Didn’t Take Effect

This is the step most tutorials skip, and it’s where support tickets pile up. A few common causes, roughly in order of how often we see them:

Shared hosting hard caps: the provider sets a maximum of 128M or 256M at the pool level, and your php.ini value is ignored without warning.
PHP-FPM pool configuration: a php_admin_value[memory_limit] entry in the pool file overrides everything in user space.
Opcode or object cache not reloaded: the config changed but PHP-FPM never restarted, so workers still hold the old value.
A plugin calling ini_set: some security and backup plugins set their own limit mid-request, occasionally lower than yours.
Editing the wrong file: multiple php.ini files exist on many servers, and only the one listed as “Loaded Configuration File” in phpinfo counts.

Find the Script That Ate the Memory

Raising the limit buys headroom; it rarely explains anything. The error message itself names a file and line number, and that single line is the fastest lead you have. Pull it from the log rather than the browser, since WordPress often hides fatal output on production sites.

Turn on logging with define('WP_DEBUG_LOG', true); and watch wp-content/debug.log, or go straight to the server-side files described in our walkthrough on monitoring WordPress PHP error logs. Then reproduce the failure deliberately: run the import, open the slow admin page, trigger the backup.

Query Monitor shows peak memory per request in the admin bar, which is enough to separate a 60M baseline from a 480M outlier. Typical culprits include large CSV or WooCommerce product imports, image regeneration across thousands of attachments, backup plugins zipping uploads in a single pass, and page builders loading every block preview at once. AI-powered plugins are a newer offender, and we covered that pattern in our notes on running heavy AI plugins without crashing the server.

Sensible Limits by Site Type

There’s no universal correct number, but these ranges hold up across most real workloads:

Blogs and brochure sites: 128M to 256M covers normal traffic and plugin loads comfortably.
WooCommerce stores: 256M as a floor, 512M during imports or large order exports. Our WooCommerce hosting accounts start at 512M for this reason.
Membership and LMS sites: 256M to 512M, since course and progress queries hold more objects in memory.
Migrations and one-off jobs: 768M temporarily, then back down once the job finishes.

Above 512M, treat the number as a symptom. Memory math matters here: if PHP-FPM runs 20 workers and each may claim 512M, the theoretical peak is 10GB on a server that might have 4GB of RAM. In practice workers rarely peak together, but a traffic spike plus a cron job can push the box into swap or trigger the OOM killer, which looks like a 502 rather than a memory error.

Frequently Asked Questions

What Is a Good PHP Memory Limit for WordPress in 2026?

256M suits the majority of WordPress sites, with 512M for WooCommerce, membership platforms and sites running 40 or more plugins. PHP’s own default is 128M, and WordPress only requests 40M by default, so most hosts set something in between.

Can I Increase the PHP Memory Limit Without cPanel or SSH?

Yes, editing wp-config.php through your file manager or FTP works on most hosts and takes about two minutes. It only succeeds if your host’s server-level cap sits at or above the value you request, so verify the result in Tools, Site Health, Info.

Why Do I Still Get the Allowed Memory Size Error After Increasing the Limit?

In roughly half the cases we see, the host enforces a hard cap in the PHP-FPM pool that overrides user settings. The other common cause is a single runaway process, such as an import loading 50,000 rows at once, that will exhaust any ceiling you set.

Does a Higher Memory Limit Make My Site Faster?

No. Memory limit is a safety ceiling, not an allocation, so a script using 80M behaves identically whether the cap is 128M or 1G. Speed comes from caching, PHP 8.3 or newer, and fewer database queries per request.

Is It Safe to Set memory_limit to -1?

Not on a live site. A value of -1 removes the limit entirely, letting one bad loop consume all available RAM and take down every site on the server. Reserve it for CLI tasks you’re supervising directly.

Get Memory Headroom Built Into Your Hosting

Every WebVibo plan ships with a 512M PHP memory limit, PHP 8.3, and engineers who will read the error log with you instead of telling you to disable plugins. See what that looks like day to day on our managed WordPress features page, or send us the error line and we’ll trace it.