Increase WordPress Memory Limit: Spot the Symptoms and Fix It

When WordPress quits in the middle of a task, uploading an image, running a plugin update, or simply loading a page, the cause is surprisingly often the same: it has run out of allocated memory. The good news: in most cases the limit can be raised in about two minutes. The honest news: sometimes a low limit is the symptom, not the cause. We’ll cover both.

How to recognise a low memory limit

The clearest signal is a specific error message, in the front end, the admin area or the log file:

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

Often you won’t see this message at all, because WP_DEBUG is off. The same problem then shows up as behaviour:

• A white screen (White Screen of Death), frequently only on certain pages, such as the media library, a page builder, or heavy WooCommerce pages. For the general approach to that symptom, see our article on the White Screen of Death.
• Updates or imports that break off: the update starts and hangs, importing large files stops without a message.
• A sluggish or partially blank admin area while the front end loads fine. The admin area is allowed more memory, so it tips over later. If it tips over anyway, you’re cutting it close.
• A fatal error when activating a memory-hungry plugin. Recent WordPress versions often show the critical-error notice then, see critical error and recovery mode.

Reading the error message: converting bytes to megabytes

The number in “Allowed memory size of … bytes exhausted” is the limit that was in force. It does not say how much memory you need. PHP hit that limit and ended the script. Divide the number by 1,048,576 (1024 times 1024) and you have megabytes:

This helps with diagnosis because it tells you which limit struck. If the message says 134217728 although you put 256M in wp-config.php, your value never took effect (more on that below). If it says 268435456, your limit did arrive and the process still wanted more.

“Tried to allocate” only names the last request PHP failed on, usually a few kilobytes. The file path behind it shows where the memory ran out, not who used it. If a plugin has already taken 120 MB, the next harmless core function is the one that fails. Don’t condemn a plugin based on the path alone.

How much memory WordPress actually needs

WordPress ships with its own defaults. According to the WordPress source (wp-includes/default-constants.php):

• WP_MEMORY_LIMIT – default 40 MB (single site) or 64 MB (multisite). This is the value for normal front-end requests.
• WP_MAX_MEMORY_LIMIT – default 256 MB, or the server’s PHP limit if that is higher. WordPress uses it in the admin area, for example for updates, and for image processing. Since WordPress 6.3 it also applies to WP-Cron tasks.

What matters is how these values interact with the PHP limit. WordPress only raises the limit via ini_set when its own value is higher than what PHP already has. It never lowers it. So if your server has memory_limit = 128M (the default according to the PHP manual) and WordPress defaults to 40M, your front end effectively runs with 128 MB. The 40 MB is a floor, not a ceiling. And if the host doesn’t allow ini_set for memory_limit, WordPress simply adopts the server value and your constants do nothing.

40 MB would be too little for a modern install with a theme, a few plugins and WooCommerce. A realistic guideline:

• 256 MB as a solid baseline for most sites.
• 512 MB for WooCommerce shops, page builders, or sites with many active plugins.

WP_MEMORY_LIMIT or WP_MAX_MEMORY_LIMIT?

In short: use WP_MEMORY_LIMIT for everything visitors trigger, and WP_MAX_MEMORY_LIMIT for what only administrators or internal processes trigger. In wp-config.php:

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

Why two values? A front-end request runs alongside many others. When lots of visitors are on the site at once, the usage of all PHP processes adds up. The admin area is rarely busy with many people at the same time, so it can afford more. On multisite installs the lower default of 64 MB applies to WP_MEMORY_LIMIT, the rest works the same.

If you only set WP_MEMORY_LIMIT to a value above 256 MB, WordPress adopts that value for WP_MAX_MEMORY_LIMIT too, unless you define it yourself. If you want the admin area to have more than the front end, set both constants.

Measure first: how high is your limit right now?

Before you change anything, check the current value. In WordPress: Tools → Site Health → Info → Server. The current PHP memory limit is listed there. If the front-end and admin values differ, WordPress shows two lines, one of which applies to admin screens only. In the WordPress Constants section of the same tab you’ll also find what WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT currently are. That way you’ll know afterwards whether your change actually took effect.

Raising the limit: the four routes

Which route works depends on your hosting. Work through them top to bottom: wp-config.php works almost everywhere, the rest is for more specific setups. Set your value, copy the matching snippet:

Also available as a standalone page with all guides: PHP limits generator.

A quick word on the four files:

1. wp-config.php – the first thing to try. It sits in your install’s root directory. The line(s) go above the comment “That’s all, stop editing!”. This is the only place where you can set the front-end and admin limits separately. It only works if the server allows ini_set for the memory limit.
2. php.ini – when you control the server yourself (dedicated server/VPS). Applies globally, not just to WordPress. The directive is memory_limit. PHP or the web server needs a restart or reload afterwards.
3. .htaccess – Apache with mod_php only. According to the PHP manual, php_value in .htaccess on a CGI/FastCGI server causes a 500 error. If your server runs PHP-FPM or FastCGI, use .user.ini instead.
4. .user.ini – for PHP-FPM/FastCGI/CGI. Also lives in the root directory. PHP re-reads these files only every user_ini.cache_ttl seconds, and the default is 300. Allow up to five minutes before you wonder why nothing happened.

Many hosts also offer a PHP setting in the customer panel (the name varies, often PHP options or PHP configuration). Choosing a higher memory_limit there is often the cleanest route, because the host writes it into its own configuration. If you’re in the panel anyway, try it there before editing files.

After the change, reload the page and check the value again in Site Health.

Still no effect? Your host is capping it

Anything WordPress sets itself can only raise the PHP limit as far as your host allows. If the server enforces a hard limit below your target value, the server wins, no matter what’s in wp-config.php.

If none of the four routes changes anything:

• Check in Site Health whether the value moved at all. If the number in the report stays the same, your value isn’t arriving.
• Look at the error message. If it still shows the old byte count, it’s the same limit as before.
• Ask your host for the maximum permitted memory_limit. Many shared hosting plans cap out at 128 or 256 MB.
• When in doubt, it’s a plan question, not a configuration question.

Which value makes sense, and why “just 1G” is a bad idea

The most common shortcut: if 256 MB isn’t enough, set 1G or go straight to -1 (unlimited). It works, but it fixes nothing. According to the PHP manual, the limit exists to stop badly written scripts from eating all of a server’s memory. Setting it very high switches off exactly that protection.

Three reasons not to:

• The problem gets bigger, not smaller. A plugin with a memory leak now uses 900 MB instead of 250 before it fails, and slows the whole server down in the meantime.
• Several processes run in parallel. If every request may take generous amounts of memory, it adds up with many simultaneous visitors. The server only has so much memory in total.
• You lose the warning signal. An error at 256 MB points to a problem you can solve. At 1 GB the same problem surfaces much later.

My rule of thumb: start at 256 MB. Go to 512 MB when a specific, repeatable task fails (an import, a page-builder request, a large shop export) and you’ve measured its usage. Anything above that needs a reason you can name.

Cause instead of symptom: what is eating the memory?

A higher limit is the right answer when your site has simply grown. It’s the wrong answer when a single plugin or a runaway database query is eating the memory. Signs of that: demand keeps climbing, you have to bump the limit regularly, or the error reproduces reliably on one specific action.

Here is how to go about it:

1. Measure usage. The Query Monitor plugin adds an admin toolbar menu with an overview of the current page. That includes peak memory usage relative to the PHP limit (based on memory_get_peak_usage in the plugin’s source). Load the failing page or action with it. If the peak sits at 90 percent of the limit, the task really is memory-hungry. If it sits at 30 percent and the error happens anyway, something else is wrong.
2. Log errors. With WP_DEBUG and WP_DEBUG_LOG set to true, WordPress writes errors to wp-content/debug.log. There you see when and during which action the error occurred. Don’t show errors to visitors (WP_DEBUG_DISPLAY set to false), and switch debugging off again afterwards.
3. Bisect the plugins. Deactivate all plugins, then reactivate them in halves until the error returns. If you can’t reach the admin area for this, rename the wp-content/plugins folder via FTP. On a live site, better do this on a staging copy.
4. Check the theme. Switching to a default theme shows whether the cause lies there.

If memory only runs short after many weeks although nothing new was added, look at the database: very large autoloaded options can bloat every request. How to find them is covered in optimizing the WordPress database. This line, “more memory” versus “real cause”, is part of what we handle in WordPress maintenance instead of cranking the limit ever higher. An overview of other error patterns is in the overview of WordPress errors.

Telling memory limit, max execution time and upload limit apart

These three limits get mixed up constantly, because they sit in the same corner of the configuration and all end in “WordPress breaks”. But they cap different things:

• Memory limit (memory_limit): how much RAM a PHP process may use. Error: “Allowed memory size … exhausted”.
• Max execution time (max_execution_time): how long a script may run. Error: “Maximum execution time exceeded”. A guide is here: fix Maximum execution time exceeded.
• Upload limit (upload_max_filesize and post_max_size): how large an uploaded file may be. For that, see increase the WordPress upload limit.

An example of how they interact: you upload a large image, the upload limit is fine, but image processing (WordPress generates several sizes) needs more memory than PHP allows. Result: a memory error although the upload itself went through. Conversely, a higher memory limit does nothing if the file already fails at the upload limit. So read the error message before you turn the first dial you find.

If your site keeps hitting the memory limit or breaks at shifting points, the value is rarely the real issue – there’s a specific culprit. If you’d rather not track it down yourself: drop us a line and we’ll look at what’s pulling the memory.