How to Increase WordPress Memory Limit

Your site dies mid-import, the Elementor editor spins forever, or wp-admin goes white, and the WordPress memory limit is the usual suspect. It is also the setting most guides tell you to raise without explaining what you are raising, where the number comes from, or why your edit did nothing. Here is what the limit actually is, all four places it can be set, how to confirm the change took, and how to spot the plugin really at fault.

What the WordPress memory limit actually is

There is no such thing as WordPress memory. There is PHP memory, and there are two WordPress constants that ask PHP nicely for more of it.

PHP caps how much RAM a single script may allocate with a directive called memory_limit. The PHP manual gives its default as 128M, and a value of -1 means no limit at all. That cap is per request, not per site. Twenty visitors hitting a 256M site do not share 256M between them; each of the twenty PHP workers can climb to 256M on its own. This is exactly why hosts are stingy with it, and why the number is set at the server rather than left to you.

WordPress then layers WP_MEMORY_LIMIT on top. Per the official wp-config.php documentation, it defaults to 40M on a single site and 64M on multisite. Those numbers look alarming next to PHP’s 128M, and they confuse people constantly, so here is the part that matters: WordPress only ever raises the limit, never lowers it. The core function that sets the constants reads the current PHP value first and calls ini_set() only when your constant is higher. Set WP_MEMORY_LIMIT to 40M on a server already serving 256M and precisely nothing happens. You keep the 256M.

That is also why the default of 40M is harmless. It is a floor, not a ceiling.

Read the error before you change anything

Memory exhaustion has one specific signature, and it is worth learning because three unrelated failures produce a similar-looking white page. PHP emits this:

Fatal error: Allowed memory size of 268435456 bytes exhausted
(tried to allocate 20480 bytes) in /home/site/public_html/wp-content/plugins/some-plugin/class-thing.php on line 214

Two numbers, both in bytes. Divide by 1048576 to get megabytes: 268435456 is 256M, so that site was already at 256M and blew through it. The second number is how much the script wanted when it died, and it is usually tiny, because the last allocation before a wall is rarely the greedy one. Note the file path too, but do not trust it yet. We come back to why in a moment.

If you see a blank page instead of that text, PHP display errors are off, which is correct on a production site. Get the message from one of these:

• The debug log. Add define( 'WP_DEBUG', true ); and define( 'WP_DEBUG_LOG', true ); to wp-config.php, reproduce the crash, then read /wp-content/debug.log. Turn both back off afterwards.
• Your host’s PHP error log. Most panels expose it under Logs or Errors. This works even when the crash happens before WordPress loads.
• The recovery mode email. Since WordPress 5.2, core catches fatal errors from plugins and themes and emails the admin address a message titled Your Site is Experiencing a Technical Issue, naming the extension involved and including a link to log in with that extension paused.

If the error says anything other than Allowed memory size, stop here. A gateway timeout is a server response time problem, and an Error establishing a database connection is a database problem. Neither is fixed by a bigger number.

Check your current limit first

You cannot fix a number you have not read. In wp-admin go to Tools, Site Health, Info, and open the Server panel. WordPress reports a field labelled PHP memory limit. If the front end and the admin area run at different values, core splits it into two rows and adds one labelled PHP memory limit (only for admin screens), which tells you immediately that a separate admin ceiling is in play.

Scroll further down the same screen to the WordPress Constants panel and you get WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT printed as WordPress resolved them for this request. Between those two panels you can see exactly what you asked for and what you actually got, which is the whole diagnosis in one screen.

Four places to set the WordPress memory limit

They are not interchangeable, and one of them can take your site offline. Work down the list and stop at the first that works.

Where	Scope	Works when	Risk if wrong
1. wp-config.php	WordPress only	Your host lets PHP change memory_limit at runtime	Low; a wrong value is ignored, but a syntax error white-screens the site
2. php.ini	Whole PHP install or directory	You have a private php.ini and can restart PHP	None; ignored if not read
3. .htaccess or .user.ini	Directory and below	.htaccess on Apache with mod_php; .user.ini on CGI or FastCGI, including PHP-FPM	.htaccess: HTTP 500 on every page. .user.ini: none, but cached up to 5 minutes
4. Host control panel	Whole account or site	Managed hosting, or when the file methods are locked down	None; the panel validates the value

1. wp-config.php, the one to try first

Open wp-config.php in the root of your install. Recent versions of the file carry a comment that reads Add any custom values between this line and the “stop editing” line. Put it exactly there:

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

Placement is not cosmetic advice. The stop editing comment sits directly above require_once ABSPATH . 'wp-settings.php';, and that require is what boots WordPress and defines the memory constants. A define written below that line runs after the entire request has already finished. It does nothing, throws a constant already defined notice, and sends people off changing php.ini for no reason. This is the usual reason a define appears to do nothing at all.

Use straight quotes, not curly ones. If you edited the file in Word or Notes, retype the line in a plain text editor.

2. php.ini, the real setting

wp-config.php can only ask PHP to raise its own ceiling at runtime. php.ini is the ceiling. If your host gives you one, find the line and edit it:

memory_limit = 256M

Two catches. First, a php.ini dropped in your web root is only read on some CGI and FastCGI setups, and is ignored entirely on many others, which is why people edit it and see no change. Second, changes to the real php.ini need PHP restarted, and on shared hosting you cannot do that yourself. Site Health tells you within a minute whether the file was read at all.

3. .htaccess, and the modern replacement for it

Every older tutorial, including the version of this one we just replaced, tells you to add this to .htaccess:

php_value memory_limit 256M

php_value is a directive supplied by the Apache module build of PHP. If your server runs PHP-FPM, FastCGI or plain CGI, and most decent hosting has for years, Apache does not recognise the directive and returns HTTP 500 on every request to that directory. Your whole site, not just wp-admin. Keep an FTP client open before you save, and delete the line the moment the site goes dark.

On a FastCGI or PHP-FPM host, the equivalent is a file named .user.ini in your web root, containing the same syntax as php.ini:

memory_limit = 256M

The PHP manual is explicit that .user.ini files are processed only by the CGI and FastCGI SAPI, and that PHP caches them for user_ini.cache_ttl seconds, which defaults to 300. So the file is safe to add, cannot 500 anything, and may take five minutes to show up. Add it, make a coffee, then recheck Site Health rather than concluding it failed.

4. The host control panel

On managed hosting this is usually the only method that works, and it is the one to reach for first if you are on a plan where the other three are locked down. Look for a PHP settings, PHP options or MultiPHP INI Editor screen. cPanel, Plesk, RunCloud and every managed WordPress dashboard has some version of it, and they all write to php.ini or .user.ini for you.

If your panel has no such screen and support will not raise the value, that is a hosting limitation rather than a WordPress one, and it is worth reading our guide to choosing hosting for a WordPress site before you spend another evening on it.

Verify the change actually took

Do not skip this. Every method above can fail silently, and the failure mode is identical to success: no error message.

1. Hard refresh wp-admin, then go back to Tools, Site Health, Info, Server and read PHP memory limit. It should show your new value.
2. Check the WordPress Constants panel on the same screen. WP_MEMORY_LIMIT should echo what you defined. If the constant shows 256M but the PHP memory limit still shows 128M, your host has blocked runtime changes and you need method 2, 3 or 4.
3. Reproduce the original crash. A limit that reads correctly and still dies means the limit was never the problem.

If you used .user.ini and see no change, wait five minutes for the cache and look again before touching anything else.

WP_MEMORY_LIMIT vs WP_MAX_MEMORY_LIMIT

These two get pasted together in every tutorial with no explanation, so people set them to the same value and lose the benefit of having two.

WP_MEMORY_LIMIT applies to every request, including the front end that your visitors and Googlebot hit. WP_MAX_MEMORY_LIMIT defaults to 256M and applies only to heavy back-end work. Core exposes it through a function called wp_raise_memory_limit(), which runs in exactly three contexts: admin (called when wp-admin loads), image (resizing and editing uploads) and cron. The front end never sees it.

The split exists because the jobs are different. Serving a cached blog post is cheap. Regenerating three thousand thumbnails, running a plugin update, or importing a WooCommerce CSV is not. Giving the admin area headroom that public page loads never touch means one greedy import cannot make every PHP worker on the box balloon at once.

So set them differently. 256M and 512M is a sane pairing. Setting both to 512M just hands the front end memory it will never use, and makes it easier for a traffic spike to exhaust the server. If your image edits are what keeps dying, the cheaper fix is usually to stop feeding WordPress 6000px camera originals, which is what a good image optimization plugin is for.

What to do when the host caps it

Sooner or later you hit a wall the define cannot climb. WordPress checks whether PHP will accept a runtime change at all, and when the answer is no it quietly adopts whatever the server already allows. Your constant is not honoured, no warning appears, and Site Health shows the two panels disagreeing. That is the tell.

What the cap looks like in practice varies more than you would expect. Kinsta ships 256MB per site and sells more as a paid add-on rather than letting you edit it. WP Engine’s own instructions tell you to add the 256M and 512M defines to a marked section of wp-config.php. Budget shared plans often sit at 128M with no panel control at all, which is one of the real trade-offs behind the cheapest WordPress hosting plans.

Your options, in the order we would actually try them:

• Open a ticket and quote the fatal error. Paste the exact Allowed memory size line. Support raise limits for a specific reproducible error far more readily than for a vague request, and on many shared plans a one-off bump to 256M is a two-minute job for them.
• Move the heavy job off the web request. Big imports, exports and thumbnail regeneration run far better through WP-CLI, which uses the command line PHP configuration and often has a much higher or unlimited memory limit than the web SAPI. Same server, different ceiling.
• Cut the demand instead of raising the supply. Deactivating one bloated plugin usually frees more memory than any define. More on that next.
• Change hosts. A host that will not give a WooCommerce store 256M in 2026 is telling you something. Our comparison of WordPress hosting platforms covers who is generous here.

For context on what to aim for, WooCommerce’s published server requirements ask for a WordPress memory limit of 256MB or greater. That is a shop with products, and it is a reasonable benchmark even if you do not run a WooCommerce store.

How to tell whether a plugin is the real cause

Here is the part that costs people the most time. The file named in the fatal error is usually innocent.

Memory exhaustion is cumulative. Thirty plugins load, each taking a modest bite, and the request crosses the ceiling somewhere around plugin twenty-nine. PHP blames whichever line asked for the byte that broke it, which is often a small, well-behaved plugin that had the misfortune of loading last. The same logic applies to the recovery mode email: core names the extension the fatal occurred inside, and for memory errors that attribution is close to arbitrary. Disabling that plugin makes the error move to a different plugin rather than go away, and that behaviour is itself the diagnosis.

Three approaches, cheapest first:

1. Measure peak usage per page. Install Query Monitor, free, version 4.0.7 with 200,000+ active installs. Its admin bar shows peak memory and the query count for the current page, and it breaks timings down by component. A page sitting at 90M when your limit is 128M is a page about to fall over.
2. Bisect with troubleshooting mode. Health Check and Troubleshooting disables plugins for your session only, so visitors keep seeing a working site while you switch things off one at a time. Worth knowing before you install it: the plugin has 300,000+ active installs but its last release, 1.7.1, dates from July 2024, so it lags current WordPress by a wide margin. It still works for this purpose; treat it as a tool you enable, use and remove.
3. Halve the problem on a copy. If bisecting live is too risky, clone to staging and deactivate half your plugins. Crash gone means the culprit is in the half you switched off. Repeat. Five rounds finds one plugin out of thirty.

Plugin versions and install counts checked August 2026 against the WordPress.org listings linked above.

Known heavy hitters, in fairness rather than as an accusation: page builders that load their full editor stack on the front end, anything doing image processing in PHP, related-posts and popular-posts plugins that query without limits, and multiple caching or optimization plugins fighting each other. Elementor Pro comes up a lot here, largely because it is installed everywhere, and because its editor loads a builder stack that front-end page views never touch. A lean asset manager such as Perfmatters can stop plugin assets loading on pages that never use them, which reduces the per-request footprint rather than just the file count.

What most guides get wrong about the memory limit

Four things, and they are the reason this article exists.

More memory is not more speed. This is the big one. The limit is a ceiling, not an allocation. Raising it from 128M to 512M does not give any page more resources; it only changes the point at which PHP kills the script. A page that used 60M before will use 60M after. If pages feel slow, the fix is a caching plugin that stops PHP running at all for most visitors, or the broader work in our guide to speeding up a WordPress site. Neither has anything to do with this number.

1024M is not a fix. Setting a very high limit on a site that genuinely needs it is fine. Setting one because 512M was not enough is how you turn a fast crash into a slow one, and on a container with a fixed RAM allocation it is how you get the process killed by the host instead, which produces a far less helpful error.

Never use -1 on a public site. Some guides suggest it. Unlimited means one runaway loop can consume every byte the server has, and takes down every other site on the box with it. If you must, use it in WP-CLI for a single import and never in wp-config.php.

The 40M default is not your problem. Because WordPress only raises and never lowers, the 40M default is invisible on any host running a sane php.ini. People find that number in a tutorial, panic, and start editing files on a site that already had 256M. Read Site Health first.

What breaks when you raise it

• The .htaccess line 500s the whole site. On any FastCGI or PHP-FPM host, php_value is an unrecognised directive and Apache refuses every request in that directory and below. Symptom: instant HTTP 500 on the front end and wp-admin together. Fix: delete the line over FTP. This is the method most likely to take your site down, which is why it is third on the list and not first.
• A stray character in wp-config.php white-screens everything. A missing semicolon, a curly quote pasted from a document, or whitespace after a closing PHP tag. Edit over SFTP with a backup of the original file sitting next to you, never in the host’s browser editor with no undo.
• Your host’s resource monitor starts complaining. On plans metered by RAM, raising the per-request ceiling raises your worst-case usage. You may trade a fatal error for a throttling notice. That is usually the better trade, but it is a trade.
• The real bug hides for another month. A plugin leaking memory on every request will exhaust 512M just as reliably as it exhausted 128M, only later and with a bigger blast radius. If you raised the limit and the crash came back, do not raise it again.

Which method should you use

• Self-hosted, you have SFTP: wp-config.php, then verify. Done in two minutes for the large majority of sites.
• wp-config edit had no effect: your host blocks runtime changes. Go to the control panel, or .user.ini if there is no panel setting.
• Managed WordPress host: the panel or a support ticket. Do not touch .htaccess.
• Old-school shared Apache host with mod_php: .htaccess works, but try wp-config.php first anyway because a wrong value is simply ignored.
• Already at 512M and still crashing: stop editing configuration. Install Query Monitor and find the plugin.

Frequently Asked Questions

The short version

Read Site Health before you edit anything. Then put two lines in wp-config.php, above the stop editing comment, setting WP_MEMORY_LIMIT to 256M and WP_MAX_MEMORY_LIMIT to 512M. Reload Site Health and confirm the server panel agrees with the constants panel. That sequence resolves most WordPress memory limit errors, and it takes about three minutes.

If the numbers do not move, your host has locked the value and the fix is the control panel or a support ticket, not another file edit. And if the numbers move but the crash comes back, stop raising the limit. You are past the point where memory is the problem, and the next hour is better spent in Query Monitor finding the plugin that thinks a page load is a good time to query every post in the database.