How to Fix WordPress Memory Exhausted Error: Complete Guide

WordPress Beginner 7 min read Published July 2025

Few errors stop a WordPress site as abruptly as the memory exhausted fatal error. One moment your dashboard and pages load normally; the next, every request returns a white screen or a stark PHP message: Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /var/www/html/wp-content/plugins/.... The number after "Allowed memory size of" is your current PHP memory_limit expressed in bytes — 134217728 bytes equals 128 MB.

This error means a single PHP request tried to allocate more RAM than PHP was allowed to give it. WordPress itself, every active plugin, and your theme all share that one memory pool for each request. When the total demand exceeds the limit, PHP aborts the request with a fatal error and WordPress cannot finish rendering the page.

The good news: this is almost always fixable without reinstalling WordPress. In most cases you either raise the limit to match what your stack legitimately needs, or you remove the component that is leaking memory. This guide walks through both, with copy-paste commands for WP-CLI, php.ini, and wp-config.php.

What is the WordPress Memory Exhausted Error?

The "memory exhausted" error is a PHP fatal error triggered when a script attempts to allocate more memory than the memory_limit directive allows for a single request. WordPress defines its own ceiling through the WP_MEMORY_LIMIT constant (and WP_MAX_MEMORY_LIMIT for the admin), but it can never exceed what PHP itself permits.

A typical message looks like this:

Fatal error: Allowed memory size of 134217728 bytes exhausted
(tried to allocate 20480 bytes) in
/var/www/html/wp-content/plugins/bulk-image-optimizer/class-resizer.php on line 187

The first number is the configured limit (here 128 MB). The path and line number point at the exact file that requested the final allocation — but that file is not necessarily the culprit. It may simply be the script that tipped an already-loaded site over the edge. Read the path to understand the context, then investigate with the diagnostic commands below.

It is important to distinguish a one-off spike (a large image upload, a CSV import, a report export) from a chronic leak (every page request approaches the limit). A one-off spike is fixed by raising the limit; a chronic leak is fixed by finding and removing the offending code. Treating a leak by endlessly raising the limit only delays the crash.

Common Causes

Step-by-Step Fix Guide

Work through the steps in order. Stop as soon as the error disappears, but always complete Step 6 to confirm the limit is actually live.

Step 1: Enable WP_DEBUG and Read the Fatal Error

Before changing any limits, confirm the error is really about memory and find which file triggers it. Open wp-config.php and enable debugging above the /* That's all, stop editing! */ line:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Reload the failing page, then read wp-content/debug.log. The fatal error entry names the file and line. With WP-CLI you can toggle these flags and log the current usage:

wp config set WP_DEBUG true --raw
wp config set WP_DEBUG_LOG true --raw
wp eval 'error_log( memory_get_usage( true ) );'

Step 2: Increase WP_MEMORY_LIMIT in wp-config.php

Add the two memory constants above the stop-editing line. WP_MEMORY_LIMIT covers the front end; WP_MAX_MEMORY_LIMIT raises the ceiling for admin-side tasks such as image processing.

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

Verify that WordPress now sees the new value:

wp config get WP_MEMORY_LIMIT
wp eval 'echo ini_get("memory_limit");'

Step 3: Raise the PHP memory_limit in php.ini

If WP_MEMORY_LIMIT has no effect, PHP is capping it. Locate and edit the correct php.ini — the CLI and FPM files are separate, and only the FPM file affects web requests:

php -i | grep "Loaded Configuration File"
sudo nano /etc/php/8.2/fpm/php.ini

Set the directive, then restart PHP-FPM so the change takes effect:

; In php.ini
memory_limit = 512M
sudo systemctl restart php8.2-fpm

Step 4: Increase Memory Through .htaccess (Apache)

On Apache without PHP-FPM, you can raise the limit per site. Add this line to your .htaccess:

# Add to .htaccess (Apache only; Nginx ignores this)
php_value memory_limit 512M

Nginx ignores .htaccess entirely. For Nginx + PHP-FPM, edit php.ini as described in Step 3.

Step 5: Find and Disable the Memory-Hungry Plugin or Theme

If the limit is already 512 MB and the error still appears, a component is leaking. Deactivate all plugins, then re-enable them one at a time:

wp plugin deactivate --all
# re-enable one by one, reloading the page after each
wp plugin activate contact-form-7

Check the theme by switching to a bundled default:

wp theme activate twentytwentyfive

Watch debug.log after each change. The component that pushes memory usage past the limit is the culprit — update it, replace it, or contact its developer.

Step 6: Optimize Image Processing and Verify the Fix

Large images are the most common legitimate spike. Upload smaller source files, raise the per-request limit for image tasks, or schedule bulk operations off-peak. Finally, confirm the new limit is live and that a typical page stays well under it:

php -i | grep memory_limit
wp eval 'echo "Peak: " . memory_get_peak_usage( true ) . "\n";'

If peak usage on a normal page is close to the limit, keep investigating — you have a leak, not a spike.

WordPress Diagnostic Commands

These commands help you read the current limit, confirm where it comes from, and measure real usage.

# Current effective memory limit seen by WordPress
wp eval 'echo ini_get("memory_limit");'

# PHP's own configuration
php -i | grep memory_limit

# Confirm the WP constant is defined in wp-config.php
grep -i memory wp-config.php

# Peak memory used by a single request
wp eval 'echo memory_get_peak_usage(true) . " bytes\n";'

# List active plugins to spot bloat
wp plugin list --status=active

# Free system RAM (server-level, not PHP)
free -m

A small PHP helper you can drop into a must-use plugin to log per-request usage:

add_action( 'shutdown', function () {
    if ( defined( 'WP_DEBUG_LOG' ) && WP_DEBUG_LOG ) {
        error_log( sprintf(
            'Memory peak: %s / %s on %s',
            size_format( memory_get_peak_usage( true ) ),
            ini_get( 'memory_limit' ),
            $_SERVER['REQUEST_URI'] ?? '/'
        ) );
    }
} );

Quick Reference Table

Symptom Likely Cause Fix
Error only on one page (media upload, product import, report export) One-off memory spike from large data Raise WP_MEMORY_LIMIT to 512M for that task
Error on every page request Chronic memory leak in a plugin or theme Disable plugins to isolate (Step 5)
Changing WP_MEMORY_LIMIT has no effect PHP memory_limit caps it below the WP setting Raise memory_limit in php.ini (Step 3)
Error appears right after installing a new plugin or theme New code leaks or loads too much at once Deactivate the newly added component
Error during image upload or optimization Large image processed fully in memory Reduce image size, batch off-peak, raise admin limit
128M or 256M still shown despite a php.ini change Wrong php.ini edited or PHP-FPM not restarted Confirm with php -i, then restart PHP-FPM
Pro tip: Do not leave WP_DEBUG and WP_DEBUG_DISPLAY set to true on a production site. Keep WP_DEBUG_LOG as true and set WP_DEBUG_DISPLAY to false so errors are written to wp-content/debug.log without being shown to visitors.

FAQ

How much memory does WordPress actually need?

A lean WordPress install with a few well-written plugins runs comfortably at 128 MB. A typical WooCommerce or membership site with a page builder usually needs 256 MB. Heavy tasks such as bulk image processing, PDF generation, or large CSV imports often need 512 MB. Start at 256 MB and raise it only when a legitimate task requires more.

What is the difference between WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT?

WP_MEMORY_LIMIT applies to the front end and general requests. WP_MAX_MEMORY_LIMIT is the higher ceiling WordPress switches to for memory-intensive admin tasks, such as regenerating thumbnails or running certain cron jobs. Both are capped by PHP's memory_limit, so if PHP is set lower, the WP constants cannot exceed it.

Can I set memory_limit to -1 (unlimited)?

Technically yes — -1 removes the per-request cap — but it is strongly discouraged. A single runaway script can then consume all server RAM and take down every site on the server. Always set a concrete limit (for example 512 MB) so a leak fails loudly instead of silently starving the machine.

Why does the error come back after I raised the limit?

You raised the ceiling but did not fix the leak. The site simply uses more memory until it hits the new cap. Re-enable WP_DEBUG, watch debug.log, and use the diagnostic commands to find which plugin or theme keeps climbing. Raising the limit is a valid fix for a spike; it is never a real fix for a leak.

Conclusion

The WordPress memory exhausted error looks scary but has a small set of root causes: a limit that is too low, a PHP configuration that caps it, or a plugin or theme that leaks. Read the fatal error message first — it tells you the current limit and the triggering file. Raise WP_MEMORY_LIMIT and the PHP memory_limit together, verify the change with php -i and WP-CLI, and if the error returns, isolate the offending component rather than endlessly raising the ceiling.

Once the site is stable, leave WP_DEBUG_LOG enabled with display off, and monitor peak memory on a few representative pages. A healthy site runs well below its limit on every request — that is the real signal that the fix is complete.

Related Guides