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! */ 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. Think of memory_limit as a fuel tank, not a speedometer: PHP isn’t telling you the car is going too fast, it’s telling you the tank ran dry mid-trip. A bigger tank gets you further, but if something under the hood is leaking fuel, you’ll run dry again regardless of tank size — you just bought yourself more miles before the next stall. If the crash comes back at a higher number, that’s the leak talking: code 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. The number after “tried to allocate” tells you the size of the final straw, not the size of the problem — use this table to translate whatever byte count your own error shows:

Bytes in the error	MB equivalent
134217728	128M
268435456	256M
536870912	512M
1073741824	1024M (1G)

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.

Constant	Default if unset	What it governs
WP_MEMORY_LIMIT	40M, or the PHP memory_limit if that is already higher	Front-end requests: normal page loads, REST API calls
WP_MAX_MEMORY_LIMIT	256M	Admin-side requests: media library, plugin/theme updates, import/export

Both are overridden by whatever your host’s PHP hard cap allows — see step 3 below for how to confirm the value that is actually live, not just the value you set.

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. Our wp-config.php guide shows where the file is and how to edit it safely.

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

   php_value only works inside .htaccess on Apache with mod_php loaded — that is the module that reads the directive. nginx never reads .htaccess files at all, so on nginx the line is simply ignored, not the cause of a 500. The 500 case to watch for is Apache running PHP through PHP-FPM (mod_proxy_fcgi) instead of mod_php: there, Apache still reads .htaccess, but the PHP-FPM handler doesn’t understand php_value and the request fails. If you get a 500 after adding it, that mismatch is why — remove it and use .user.ini. The same .user.ini-vs-.htaccess split trips people up on other per-host PHP settings too, like post_max_size and upload_max_filesize — our increase upload limit guide walks through that version of the same mechanism.

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-Five. 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. If you are not sure where debug.log lives or it is not appearing, the debug log location guide covers where WordPress writes it by default and how to move it. Set WP_DEBUG back to false once you have it; the WordPress debug mode guide covers turning it off cleanly.

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.

Sources

• WordPress Developer Resources: wp-config.php (WP_MEMORY_LIMIT, WP_MAX_MEMORY_LIMIT)
• WordPress source code: default-constants.php
• PHP manual: memory_limit, .user.ini files, How to change configuration settings