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/...

The number is the current limit in bytes (134217728 = 128 MB). PHP needed more and bailed out.

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 – the media library, a page builder, or heavy WooCommerce pages.
• 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 gets a higher allowance, so it tips over later – a sign you’re cutting it close).
• A fatal error when activating a memory-hungry plugin.

If any of that sounds familiar, it’s worth checking the limit.

How much memory WordPress actually needs

WordPress ships with its own defaults that apply regardless of the server:

• WP_MEMORY_LIMIT – default 40 MB (single site) or 64 MB (multisite). This is the front-end limit.
• WP_MAX_MEMORY_LIMIT – default 256 MB. WordPress only uses this higher limit in the admin area for heavy tasks such as image processing.

40 MB is simply too little for a modern install with a theme, a handful of 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.

More is not automatically better – a permanently very high value can mask an underlying problem (see below).

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 value is listed under “PHP memory limit”. That way you’ll also 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:

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.
2. php.ini – when you control the server yourself (dedicated server/VPS). Applies globally, not just to WordPress.
3. .htaccess – Apache with mod_php only. If your server runs PHP-FPM or FastCGI, this line throws a 500 error. Use .user.ini instead.
4. .user.ini – for PHP-FPM/FastCGI/CGI. Also lives in the root directory. The change takes effect after a short delay.

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

Still no effect? Your host is capping it

WP_MEMORY_LIMIT 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.
• 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.

Symptom versus cause

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.

In that case a bigger number won’t help – you need to find the culprit, usually via WP_DEBUG_LOG, by deactivating plugins one by one, or by looking at slow queries. Drawing exactly that 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.

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.