How to Increase the Memory Limit in WordPress (4 Methods)

The “Allowed memory size exhausted” error in WordPress means PHP hit its memory ceiling while trying to run your site. The fix is straightforward — you need to raise the limit — but there are four different places you can set it, and which one works depends on your hosting environment. This guide covers all four methods in order of reliability, what the memory limits actually control, and how much memory you should actually set.

Understanding the Error

A typical memory exhaustion error looks like this:

Fatal error: Allowed memory size of 67108864 bytes exhausted
(tried to allocate 2348617 bytes) in
/home/user/public_html/wp-includes/plugin.php on line 446

The number 67108864 is 64MB in bytes (64 × 1024 × 1024). The “tried to allocate” figure is the additional memory the operation needed. The file path tells you roughly what was running at the time — in this case, the plugin loader.

There are actually two memory limits at play in WordPress:

• PHP memory limit — set in php.ini or equivalent; the ceiling for any PHP process on the server
• WordPress memory limit — set via WP_MEMORY_LIMIT in wp-config.php; what WordPress requests from PHP. WordPress won’t exceed the PHP ceiling regardless of what you set here.

WordPress also has a separate WP_MAX_MEMORY_LIMIT for the admin dashboard, which defaults to 256M and governs operations like media uploads and plugin installs. If you’re seeing memory errors only in wp-admin, this is the relevant constant.

How Much Memory Do You Need?

Default WordPress memory limit: 40MB. Minimum for a functioning site with a few plugins: 64MB. Practical minimum for a site with WooCommerce or a page builder: 128MB. Most production WordPress sites run comfortably at 256MB. Servers with many concurrent users, complex queries, or large WooCommerce catalogues sometimes need 512MB.

The right number is the lowest value at which you stop seeing memory errors — not the highest your server will allow. Raising it to 512MB when 128MB would fix the problem wastes server resources on every PHP process, not just the ones that need it.

Method 1: wp-config.php (Recommended First Step)

This is the most reliable method across all hosting environments. It sets the WordPress memory limit directly, regardless of how the server’s PHP configuration is structured.

1. Open wp-config.php in the root of your WordPress installation (via SFTP/FTP or your host’s file manager)
2. Find this line near the bottom:

   /* That's all, stop editing! Happy blogging. */

3. Add these lines above that comment:

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

4. Save the file and reload the page that was showing the error

WP_MEMORY_LIMIT controls front-end requests. WP_MAX_MEMORY_LIMIT controls the wp-admin dashboard. Setting both covers all scenarios. Start with 256M — you can reduce it later if monitoring shows it’s unnecessary.

Important: WP_MEMORY_LIMIT cannot exceed the PHP-level memory limit. If your host sets PHP to 64MB and you write 256M in wp-config.php, WordPress will still be capped at 64MB. Method 1 alone isn’t always enough — see Methods 2 and 3 if the error persists.

Method 2: php.ini

This sets the PHP-level limit directly, which is what WP_MEMORY_LIMIT is capped by. The catch: whether you can edit php.ini depends on your hosting setup.

On shared hosting with cPanel, look for a php.ini or php.ini.default file in your web root or your home directory. If one doesn’t exist, create it. Add or update:

memory_limit = 256M

On VPS or dedicated servers where you control the PHP installation, the file is typically at /etc/php/8.x/fpm/php.ini (for PHP-FPM) or /etc/php/8.x/apache2/php.ini (for mod_php). Edit directly and restart PHP-FPM or Apache after saving:

sudo systemctl restart php8.2-fpm

On managed WordPress hosting (Kinsta, WP Engine, Cloudways), you generally can’t edit php.ini yourself — managed hosts set their own PHP configuration. If Method 1 isn’t working and you’re on managed hosting, contact your host and ask them to raise the PHP memory limit for your plan. Most will do this on request.

Method 3: .htaccess (Apache Only)

If you have an Apache server and can’t access php.ini, you may be able to set the memory limit via .htaccess in your web root. Add this line:

php_value memory_limit 256M

This only works if your host runs PHP as an Apache module (mod_php) and has set AllowOverride to permit PHP directives in .htaccess. Many shared hosts don’t allow this — if it causes a 500 error, remove the line. On PHP-FPM setups (which is most modern hosting), php_value in .htaccess is ignored entirely. See the guide to .htaccess on Apache for more on where .htaccess applies.

Method 4: Multisite wp-config.php Constants

If you’re running WordPress Multisite, the memory limit set in wp-config.php applies to the network as a whole. Individual subsite plugins can still cause memory exhaustion if a single plugin installation on a subsite has unusually high requirements. In this case, consider whether that plugin is right for a multisite network, or whether it should be isolated to a standalone installation.

Verifying the Fix

After applying a method, confirm the new limit is actually in effect — not just that the error stopped appearing:

1. Create a temporary file called phpinfo.php in your web root with this content:

   <?php phpinfo(); ?>

2. Visit https://yoursite.com/phpinfo.php in a browser
3. Search for memory_limit — you’ll see the configured value and the effective value
4. Delete the file immediately after checking — phpinfo() exposes server configuration details that shouldn’t be publicly visible

Alternatively, add this line temporarily to a theme’s functions.php or use a plugin like Query Monitor (which shows the current PHP memory limit in its dashboard panel without exposing a public URL).

When Raising the Limit Doesn’t Help

If you raise the limit to 512M and still see memory exhaustion errors, something specific is consuming unusually large amounts of memory:

• A single plugin with a memory leak. Deactivate plugins one at a time while watching memory usage in Query Monitor to find the culprit. Memory leaks in WordPress plugins are more common than you’d expect — they often appear only under certain content or traffic conditions.
• A theme loading unnecessary assets. Some page builders load their full asset stack on every page regardless of whether it’s needed. A lightweight theme like Astra or Kadence uses a fraction of the memory a heavy page builder theme does. See how to choose a performant WordPress theme.
• A WooCommerce query issue. Product catalogue queries, variation lookups, and cart operations can be memory-intensive at scale. WooCommerce’s built-in performance settings (lazy-loading variations, limiting product queries) are worth reviewing before simply raising the ceiling higher.
• PHP version too old. PHP 5.x and early PHP 7 releases have higher per-operation memory overhead than PHP 8.x. If you’re running PHP 7.4 or earlier, upgrading to 8.2 or 8.4 is likely to reduce baseline memory usage across the board. See how to upgrade PHP on Ubuntu for the Apache and Nginx paths.

If memory exhaustion is causing a white screen rather than a visible error message, see how to fix the WordPress white screen of death — it covers enabling WP_DEBUG and reading the debug log to find the actual failing operation.

Preventing Memory Issues Long-Term

A few practices that keep memory problems from recurring:

• Keep PHP updated. Each major PHP version improves memory efficiency. Staying current reduces baseline memory consumption without any configuration changes.
• Audit your plugin stack periodically. Every active plugin runs on every page load (with minor exceptions). Plugins you installed to solve a one-off problem and forgot about still consume memory on every request. The WordPress maintenance guide covers plugin auditing as part of a regular housekeeping schedule.
• Use a caching plugin. A caching plugin like WP Rocket or LiteSpeed Cache serves cached HTML for most page views without running PHP at all — dramatically reducing per-request memory usage for front-end visitors. See WP Rocket vs W3 Total Cache vs LiteSpeed Cache for a comparison.
• Monitor with Query Monitor. The Query Monitor plugin (free) shows PHP memory usage for each page load in real time. Running it for a few days across your most visited pages will tell you whether memory is trending upward over time — usually a sign of a recently installed plugin with a leak.