Skip to content
Configuration

Fix "Allowed Memory Size Exhausted" in WordPress

If your site is showing Fatal error: Allowed memory size of 268435456 bytes exhausted, add this line to wp-config.php above the / That's all, stop editing! /

Published

Skip the reading — use the tool wp-config.php Generator Build a correct wp-config.php without copy-pasting from a 2014 blog post

If your site is showing Fatal error: Allowed memory size of 268435456 bytes exhausted, add this line to wp-config.php above the /* That's all, stop editing! */ comment: define( 'WP_MEMORY_LIMIT', '256M' );. That gets most sites back online in under a minute. But read the rest of this page before you walk away, because raising the limit is a diagnostic, not a cure. If the crash comes back at a higher number, the real problem is code that is consuming memory without bound, and a bigger ceiling just buys it more rope.

What the error actually means

PHP tracks how much memory each request has allocated. When a single request tries to allocate past the memory_limit set in php.ini (or overridden by WordPress), PHP kills the request immediately with a fatal error and prints the byte count it died at. 268435456 bytes is 256M. 134217728 is 128M. 536870912 is 512M. The number after “tried to allocate” tells you the size of the final straw, not the size of the problem.

WordPress layers its own limits on top of PHP. WP_MEMORY_LIMIT (default 40M, or the PHP limit if higher) governs the front end. WP_MAX_MEMORY_LIMIT (default 256M) governs admin-side operations like the media library and plugin updates, which legitimately need more. WordPress calls ini_set('memory_limit', ...) on load based on these constants — but only if your host allows ini_set, and only up to the hard cap your host sets. That last part is why editing wp-config.php sometimes appears to do nothing.

Fix it, in order

1. Raise the WordPress limit in wp-config.php. This is the first thing to try because it is reversible and touches nothing else.

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

If you are not sure where these lines go or want the other common constants set correctly at the same time, our wp-config generator writes a clean block you can paste in. Placement matters — anything below the “stop editing” line is ignored.

2. If that does nothing, your host is capping PHP. Raise memory_limit at the PHP level. In php.ini:

memory_limit = 256M

On many shared hosts you cannot edit php.ini directly. Try a .user.ini file in your web root instead, or set it via .htaccess on an Apache/mod_php setup:

php_value memory_limit 256M

Note that php_value in .htaccess throws a 500 error on nginx or on PHP-FPM setups, because it is an Apache/mod_php directive. If you get a 500 after adding it, that is why — remove it and use .user.ini.

3. Confirm the value that is actually live. Do not trust what you edited; trust what PHP reports. Drop a one-line file at your web root:

<?php echo ini_get('memory_limit');

Load it in a browser, read the value, then delete the file. If it still says 128M after you set 256M, your host is overriding you and you need to contact them or use their control panel setting.

The part most guides skip

Raising the limit is diagnosis. Here is how to read the result.

If you set 256M and the site stays up under normal traffic, you had a legitimate ceiling that was too low — common on sites with large media libraries, WooCommerce, or page builders. You are done.

If you set 256M and it crashes again, then 512M and it crashes again, stop raising it. A normal WordPress request does not need 512M. When memory use climbs without a ceiling, something is looping or accumulating: a plugin loading an entire database table into an array, an add_action that recursively triggers itself, an import routine holding every row in memory at once, or two plugins fighting inside the same hook. Raising the limit does not fix an unbounded loop — it just moves the crash a few seconds later and makes it harder to reproduce.

To find the culprit, deactivate all plugins and switch to a default theme like Twenty Twenty-Four. If the error stops, reactivate one at a time until it returns. Turn on the debug log to catch where it dies:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

The fatal line in wp-content/debug.log names the file and line number that allocated the final chunk. That is usually the loop, or one function call away from it.

What not to do

Do not set WP_MEMORY_LIMIT to -1 or 1024M and forget it. Unlimited memory does not fix a leak; it lets a runaway request eat the whole server, which can take down every other site on the same box and get you a call from your host. A ceiling is a safety feature. Keep one.

Do not paste ini_set('memory_limit', '512M') into functions.php as the primary fix. It runs too late for some failures — if the crash happens during WordPress core load before your theme’s functions.php executes, the line never runs. wp-config.php loads earlier and is the correct place.

Do not assume it is a hosting problem and upgrade your plan. Sometimes it is genuinely undersized hosting. Often the exact same crash follows you to the bigger plan because the cause shipped along in your plugins. Rule out the loop first; it is free.

Do not raise memory_limit to fix a max_execution_time error. They are different limits with different messages. Memory exhaustion says “Allowed memory size … exhausted.” A timeout says “Maximum execution time … exceeded.” Raising the wrong one wastes an afternoon.

Still stuck?

If you have confirmed the live limit is genuinely 256M or higher, tested with all plugins off and a default theme, and it still exhausts memory, you have a real leak worth chasing in the debug log rather than a ceiling worth raising. Capture the fatal line, note which plugin’s directory it points into, and that is your bug report. Get your baseline wp-config.php constants right first with the wp-config generator so you know the limits are set where you think they are — then go read the log.