WordPress Memory Limit: Raising It Properly and Finding What Ate It

Q: Why does setting WP_MEMORY_LIMIT not work?

Because PHP's own memory_limit is the hard ceiling and WordPress cannot exceed it. If PHP allows 128M, setting WP_MEMORY_LIMIT to 512M changes nothing. Raise PHP's limit first in the PHP-FPM pool config or php.ini, then set the WordPress constant at or below it.

Q: Why did adding php_value to .htaccess break my site?

php_value directives only work under mod_php. On PHP-FPM, which most modern hosting uses, they are either ignored or cause a 500 error. Use the PHP-FPM pool config or php.ini instead, and remove the .htaccess line.

WordPress has two memory ceilings and PHP’s is the one that wins. Setting WP_MEMORY_LIMIT to 512M in wp-config.php does nothing if PHP’s memory_limit is 128M, which is why the most common fix appears to fail. Raise PHP’s first, then WordPress’s, then find out what is consuming it.

The fatal error names a number, and the number is a symptom:

Two limits, and which one wins
Setting it, in order of how well it works
Confirming the change actually applied
Finding what actually consumed the memory
A sensible ceiling
How this fits the rest of the stack
FAQ

Two limits, and which one wins

Fatal error: Allowed memory size of 134217728 bytes exhausted
(tried to allocate 20480 bytes) in /wp-includes/functions.php on line 2126

134217728 bytes is 128MB — PHP’s default. That is the hard ceiling. WP_MEMORY_LIMIT is a WordPress-level constant that PHP will honour only if it is below PHP’s own limit, because a PHP process cannot raise its ceiling above what the server permits.

So the order matters:

Raise PHP’s memory_limit at the server level.
Then set WP_MEMORY_LIMIT in wp-config.php to something at or under it.
Then verify what the running process actually got.

Skip the first step and the second changes nothing, which is the single most common reason this fix is reported as not working.

Check what you currently have before changing anything, from inside WordPress under Tools → Site Health → Info → Server, or directly:

<?php
echo ini_get('memory_limit'), "\n";      // PHP's ceiling
echo WP_MEMORY_LIMIT, "\n";              // WordPress's request

Setting it, in order of how well it works

PHP-FPM pool config is the correct place on most modern hosting, and it survives WordPress updates:

php_admin_value[memory_limit] = 256M

That goes in your pool file, typically /etc/php/8.2/fpm/pool.d/www.conf. Reload PHP-FPM afterwards.

php.ini, if you have access to it:

memory_limit = 256M

wp-config.php, above the line that tells you to stop editing:

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

The second constant is separate and often overlooked. WordPress raises the limit to WP_MAX_MEMORY_LIMIT for admin-side operations specifically — the media library, imports, plugin updates — because those legitimately need more than a front-end page render.

.htaccess is the last resort, and it fails on many hosts:

php_value memory_limit 256M

On PHP-FPM, which is now the norm, php_value in .htaccess does nothing at all, and on some shared hosts it produces a 500 error. If adding this breaks the site, remove it — that is the expected result rather than a sign of something deeper.

Confirming the change actually applied

Do not trust the config file. Check what the process running your site received, because there are several layers that can override it.

<?php
// temporary file at the site root, delete after checking
phpinfo();

Look for memory_limit and note both columns — the local value and the master value. A local value lower than what you set means something is overriding it further down the chain.

Common overrides that silently win:

A caching or security plugin setting ini_set('memory_limit', ...) at runtime.
A .user.ini file in the site root, which takes precedence over php.ini and is easy to forget about.
A hosting control panel setting that rewrites the pool config on save.
A container image with the limit baked in, where your edit is to a file that is not the one being read.

Also note that .user.ini changes are cached for five minutes by default, so a change that appears not to have worked may simply not have been reloaded yet.

Finding what actually consumed the memory

Raising the limit is a valid immediate fix and a poor permanent one. A well-behaved WordPress site with a normal theme renders a page in well under 128MB. Needing 512M usually means something is loading far more than it should.

The fatal error names a file, and that is your starting point — although it usually names where the last allocation happened rather than what was responsible for the bulk of it.

The reliable way to identify the cause is bisection:

Switch to a default theme. If the problem stops, it is the theme.
Deactivate all plugins, confirm the problem stops, then reactivate in groups until it returns.
Check for a plugin running an unbounded query — posts_per_page => -1 on a site with 50,000 posts loads every one of them into memory.

Query Monitor is the tool worth installing for this. It shows memory usage, query counts and the slowest queries per page load, which usually identifies the culprit in one request.

The recurring offenders, in rough order:

Unbounded WP_Query calls in a theme or plugin.
Image processing on upload, especially large images with many generated sizes.
Imports and migrations, which genuinely need more memory and only during the operation.
Page builders holding large serialised post meta.
A plugin loading its whole dataset on every request rather than querying for what it needs.

A sensible ceiling

256M handles almost any real site. 512M covers heavy imports and large media libraries. Beyond that you are usually hiding a bug rather than accommodating a workload.

There is a real cost to setting it very high. memory_limit is per PHP process, and PHP-FPM runs many of them. A limit of 1G with 20 workers is a 20GB worst case on a server that may have 4GB. What you get is not a fast site — it is the OOM killer terminating PHP under load, which looks like random 502 errors rather than a clean memory error.

Size it against the server:

free -m
ps aux | grep php-fpm | wc -l

Workers times limit should sit comfortably below available RAM, with headroom for the database and everything else on the box.

If a site genuinely needs a high limit under normal traffic, the honest answer is more memory on the plan, not a larger number in a config file that the machine cannot back.

How this fits the rest of the stack

Memory limits are one of those settings that only exist because the alternative is worse: without a ceiling, one runaway request takes the whole server down instead of one page. Raising it is fine; raising it past what the machine has is just changing which component fails.

This is where managed WordPress earns its keep, because the plan defines the memory rather than a config file arguing with the host. RunxBuild runs WordPress on its own plan ladder from $3/month, with a file manager and a database browser in the dashboard — so editing wp-config.php or checking what a plugin is storing does not need SFTP and phpMyAdmin. Autoscaling handles the case where load, rather than a bug, is the real reason you are running out. The RunxBuild hosting calculator shows the plans against what the site actually needs.

Useful related references:

FAQ

Why does setting WP_MEMORY_LIMIT not work?

Because PHP’s own memory_limit is the hard ceiling and WordPress cannot exceed it. If PHP allows 128M, setting WP_MEMORY_LIMIT to 512M changes nothing. Raise PHP’s limit first in the PHP-FPM pool config or php.ini, then set the WordPress constant at or below it.

What is the difference between WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT?

The first applies to normal front-end page rendering. The second is what WordPress raises to for admin operations such as media handling, imports and updates, which legitimately need more. Setting only the first leaves admin-side limits at their default.

How much memory should WordPress have?

256M covers almost any real site and 512M covers heavy imports and large media libraries. Needing more than that under normal traffic usually indicates an unbounded query or a misbehaving plugin rather than a genuine requirement.

Why did adding php_value to .htaccess break my site?

php_value directives only work under mod_php. On PHP-FPM, which most modern hosting uses, they are either ignored or cause a 500 error. Use the PHP-FPM pool config or php.ini instead, and remove the .htaccess line.

How do I find which plugin is using all the memory?

Install Query Monitor, which reports memory usage and query counts per page load. If that does not identify it, bisect: switch to a default theme, deactivate all plugins, then reactivate in groups until the error returns. Unbounded WP_Query calls with posts_per_page => -1 are the most common cause.