Fix WordPress Allowed Memory Size Exhausted Error

The error you're seeing

You open your WordPress site and see a white screen, or you get an email like this:

PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted
(tried to allocate 20480 bytes) in /var/www/html/wp-includes/class-wpdb.php on line 1234

That number — 134217728 bytes — is 128 MB. It's the default PHP memory limit on many shared hosting plans. The reason your site hits it is usually a plugin gone wild, a theme with memory leaks, or a site with too many concurrent requests.

Here's the fix, in order from fastest to most thorough. Stop when your error is gone.

Fix 1: Edit wp-config.php (30 seconds)

This is the easiest and it works for most cases. Open your WordPress root folder (where wp-config.php lives) via FTP or your hosting file manager.

Find this line:

define( 'WP_DEBUG', false );

Right before it, add this line:

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

Save the file. Reload your site. If the error is gone, you're done.

Why this works: WordPress reads this constant before any plugins load. It tells PHP to allow 256 MB of memory for this request. If your host allows it (most do), this is the cleanest fix.

If you still see the error, your host may be overriding this value. Move to Fix 2.

Fix 2: Edit .htaccess (5 minutes)

If wp-config didn't stick, the host might be setting a lower limit via Apache config. You can override it with .htaccess.

Find the .htaccess file in your WordPress root. It's a hidden file — you might need to enable "show hidden files" in your FTP client.

Add this block at the very top of the file:

# Increase PHP memory limit
php_value memory_limit 256M
php_value max_execution_time 300

Save and reload. If it works, great. If not, the host may not allow PHP values in .htaccess (some shared hosts block this for security).

Don't add this at the bottom — WordPress's rewrite rules at the bottom can conflict with php_value directives at the bottom. Top of the file is correct.

Fix 3: Edit php.ini (15+ minutes)

This is the nuclear option. You need access to your server's PHP configuration. On shared hosting, you might have a php.ini in your public_html folder. On a VPS or dedicated server, you'll edit the main php.ini.

Create or edit php.ini in your WordPress root. Add this line:

memory_limit = 256M

Save and reload. If it still doesn't work, you need to find the real php.ini. On most cPanel hosts, it's at /etc/php.ini but you can't edit it. Instead, create a user.ini file in your public_html folder with the same line.

If you're on Nginx or Apache with PHP-FPM, you may need to edit /etc/php/7.4/fpm/php.ini (replace 7.4 with your PHP version) and restart PHP-FPM:

sudo systemctl restart php7.4-fpm

That's the real fix — restarting PHP-FPM makes the config stick.

Why 256 MB works, not 128 MB

128 MB was fine for WordPress 5 years ago with a dozen plugins. Now a single plugin like WooCommerce or Elementor can eat 80 MB on a page load. Plus WordPress itself uses about 40 MB. That leaves almost nothing for other plugins, media handling, or concurrent requests.

256 MB covers most sites. If you run a big WooCommerce store with many products, you might need 512 MB. But start at 256.

When none of this works

If you still get the error after all three fixes, your host is capping memory at the server level. Some budget hosts hard-limit memory to 128 MB. You'll need to contact them and ask them to increase the limit for your account, or switch hosts.

Another cause: you have a plugin that's leaking memory. Try deactivating all plugins. If the error goes away, reactivate them one by one to find the culprit. Common memory hogs: Wordfence, Jetpack, broken custom plugins.

One more thing — if your error message mentions a specific file like wp-content/plugins/some-plugin/cache.php, that plugin is the cause. Either fix the plugin or replace it.

Real trigger: People often hit this after updating to PHP 8.0+ because newer PHP versions use more memory per request due to stricter type checking and larger object sizes.