To raise the WordPress memory limit, add one line to wp-config.php above /* That's all, stop editing! */:
define( 'WP_MEMORY_LIMIT', '256M' );
That line works on most servers and silently does nothing on the rest. The rest of this post is how to tell which one you are on, because every guide gives you the line and none of them give you the test.
All the core behaviour below was read from WordPress/wordpress-develop trunk on 2026-10-01.
Core only ever raises the limit, never lowers it
wp_initial_constants() in src/wp-includes/default-constants.php is where your constant is applied. The whole decision is four lines:
$wp_limit_int = wp_convert_hr_to_bytes( WP_MEMORY_LIMIT );
if ( -1 !== $current_limit_int && ( -1 === $wp_limit_int || $wp_limit_int > $current_limit_int ) ) {
ini_set( 'memory_limit', WP_MEMORY_LIMIT );
}
Two things follow from that condition, and both of them surprise people.
If php.ini already gives you more than you asked for, nothing happens. Setting 256M on a host that already grants 512M is not a downgrade, it is a no-op, so you cannot shrink WordPress by setting a smaller value here.
If your server's memory_limit is -1, meaning unlimited, core skips the ini_set entirely. Your WP_MEMORY_LIMIT line is read, defined, and then ignored, which is usually what you want but is worth knowing before you spend an afternoon on it.
The failure is silent by design
Look at that snippet again. The return value of ini_set is not captured, not checked, and not logged.
ini_set returns false when PHP refuses the change, which is what happens when memory_limit is locked at the server level. Core does not care, so you get no warning, no admin notice and nothing in the debug log.
That is the single reason "I added the line and nothing changed" is such a common support thread. The line did run, PHP declined, and nobody told you.
The check that tells you whether your server allows it
PHP settings carry an access level, and memory_limit is only changeable at runtime when that level is INI_ALL or INI_USER. Core reads it in wp_is_ini_value_changeable() in src/wp-includes/load.php:
if ( isset( $ini_all[ $setting ]['access'] )
&& ( INI_ALL === $ini_all[ $setting ]['access'] || INI_USER === $ini_all[ $setting ]['access'] )
) {
return true;
}
If your host sets memory_limit with php_admin_value in a PHP-FPM pool, the access level drops and that function returns false. No amount of wp-config.php editing gets past it, and you need the host or the pool config.
You can ask PHP directly over SSH, which takes a second and settles the question:
php -r 'var_dump( ini_get_all()["memory_limit"] );'
An access value of 7 is INI_ALL, and WordPress can raise the limit. A 4 is INI_SYSTEM, and it cannot.
There is one trap in that function worth naming. It calls ini_get_all(), and when a host has put ini_get_all in disable_functions, core cannot read the access level and deliberately assumes the value is changeable.
WordPress then tries the raise anyway and absorbs the failure, so a hardened host is exactly where the silent path is most likely.
WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT are different numbers
WP_MEMORY_LIMIT is the floor for every request. Its default is 40M on single site and 64M on multisite, both set in the same function, and both lower than most people assume.
WP_MAX_MEMORY_LIMIT defaults to 256M, or to your php.ini value when that is higher or unlimited. It is not applied to normal page loads at all.
Instead, three places in core call wp_raise_memory_limit() to climb from the first number to the second, each with its own filter:
| Context | Called from | Filter |
|---|---|---|
admin |
wp-admin/admin.php |
admin_memory_limit |
image |
wp-includes/class-wp-image-editor.php |
image_memory_limit |
cron |
wp-cron.php |
cron_memory_limit |
So the number that applies depends on what the request is doing. Raising WP_MEMORY_LIMIT is what fixes a front-end fatal.
Raising WP_MAX_MEMORY_LIMIT is what fixes a fatal during an update, an image resize or a cron run.
Note what the cron row does and does not cover. wp-cron.php is the HTTP spawn, so a real system cron calling wp cron event run through WP-CLI never passes through that raise and runs on your CLI php.ini instead, which is frequently a different file with a different value.
Why the fatal hits your client and not you
This is the line in wp-admin/admin.php that almost no guide mentions:
if ( current_user_can( 'manage_options' ) ) {
wp_raise_memory_limit( 'admin' );
}
The admin raise is gated on a capability. An administrator gets up to 256M on every admin screen, and an editor, author, contributor or WooCommerce shop manager does not.
That is a real explanation for a bug report that sounds impossible: the same admin screen, the same plugins and the same server, fatal for one person and fine for you, with no caching involved.
Check the role before you check anything else.
Image resizing is not gated this way, which is deliberate: core's own comment says memory for processing images is handled separately because users of any role upload them.
Site Health shows you the pre-raise number
Every guide tells you to read the memory limit from Tools, then Site Health, then Info. That number is real, but it is not the limit the screen you are looking at is running under.
WP_Site_Health::__construct() captures it early, and core's comment says why:
// Save memory limit before it's affected by wp_raise_memory_limit( 'admin' ).
$this->php_memory_limit = ini_get( 'memory_limit' );
So Site Health reports your front-end limit while you read it on a screen that has already climbed to WP_MAX_MEMORY_LIMIT. If you want the live value for the context you care about, print ini_get( 'memory_limit' ) in that context.
php.ini, .htaccess, and which one your server reads
When wp-config.php cannot win, the next layer up is PHP's own configuration, and which file applies depends on how PHP is wired to the web server.
Under PHP-FPM, which is now the common setup, the value comes from the pool config or a php.ini the pool loads, and .htaccess has no part in it. Under Apache with mod_php, php_value memory_limit 256M in .htaccess does work.
Putting that directive in .htaccess without mod_php is worse than useless. Apache does not recognise the directive and answers every request with a 500, which turns a slow site into a dead one, and nginx does not read .htaccess at all so the line is simply inert.
We wrote up what core does and does not own in that file separately.
Raising the limit is a diagnosis, not a fix
A normal WordPress page load does not need 256MB. If yours does, the honest reading is that something is holding a large array or a full result set in memory, and the higher limit buys you the time to find it, not the fix.
Raise it to get the site back, then turn on WP_DEBUG_LOG and find the request that consumed it. The fatal itself tells you where the last allocation happened, and that file and line is usually the answer.
Our Debug mode toggles WP_DEBUG, WP_DEBUG_LOG and WP_DEBUG_DISPLAY and gives you the log in the browser, which is faster than going in for wp-content/debug.log by hand. The same approach works for the related white screen of death, where a memory fatal is one of the three usual causes.
Change it on a copy, not on the live site
Every method above either edits a file PHP parses on every request or changes a server setting, and a typo in wp-config.php takes the whole site down rather than showing a warning.
A disposable copy removes that risk. Clone the site, change the limit there, reproduce the fatal, confirm the new value actually took effect, and only then touch production.
Our Cloner makes the copy, and resetting the sandbox undoes whatever you broke while testing.
Every SandyWP sandbox starts with memory_limit at 256MB, and you can set it anywhere from 64MB to 512MB in the PHP configuration panel without editing a file. The effective ceiling sits below the sandbox's container memory, because PHP needs headroom inside it.
The useful part of testing on a sandbox is not the higher number. It is that you can set the limit low on purpose, reproduce the fatal on demand, and then prove which of the four methods above your server actually honours.
