WordPress Memory Limit: How to Check, Increase, and Fix Exhausted Memory Errors

Your WordPress site just threw a “Fatal error: Allowed memory size exhausted” message, and the whole thing stopped loading. It’s one of the most common WordPress errors, and it happens when a PHP script tries to use more memory than your server allows. The good news is that fixing it usually takes about two minutes and a single line of code.

The WordPress memory limit is a cap on how much RAM each PHP process can use while running your site. WordPress sets its own default at 40 MB for a standard install, which was fine years ago but falls short the moment you add a page builder, a caching plugin, or a handful of active extensions. When a script hits that ceiling, PHP kills it mid-execution and you get the white screen or the fatal error notice.

You can raise the limit yourself by adding define(‘WP_MEMORY_LIMIT’, ‘256M’); to your wp-config.php file, right above the line that says “stop editing.” That single change resolves the error for most sites. If it doesn’t, there are two more methods (your .htaccess file and php.ini) and a deeper diagnosis process covered below, including how to track down which plugin is actually eating all that memory in the first place.

This article walks through every angle of the WordPress memory limit: what it actually controls, how to check your current setting, three proven ways to increase it, and what to do when none of those methods stick. Whether you’re running a simple blog or a full ecommerce store, you’ll leave with a working fix and a plan to keep memory issues from coming back.

Every web server has a finite amount of RAM, and PHP uses a configuration value called memory_limit to control how much of that RAM any single script can consume. WordPress adds its own layer on top with the WP_MEMORY_LIMIT constant, which tells WordPress how much memory it should request from PHP for front-end operations like loading pages and processing forms.

There’s a critical hierarchy to understand here. The PHP memory_limit set by your hosting provider is the hard ceiling, and WordPress can’t exceed it no matter what you put in wp-config.php. Think of it this way: your host says “each script gets up to 512 MB,” and then WordPress says “I’ll use up to 256 MB of that.” If your WP_MEMORY_LIMIT is set higher than the server’s PHP memory_limit, WordPress simply won’t get more than the server allows.

WordPress actually has two separate memory constants, and most articles only mention one. WP_MEMORY_LIMIT controls memory for front-end page loads, while WP_MAX_MEMORY_LIMIT controls memory for admin tasks like editing posts, uploading media, and running plugin operations in the dashboard. WordPress defaults WP_MAX_MEMORY_LIMIT to 256 MB, which is why you might see the error only on the front end while the admin keeps working fine. If your dashboard is the one crashing, you’d need to raise WP_MAX_MEMORY_LIMIT specifically.

The default WP_MEMORY_LIMIT is 40 MB for a standard single-site install and 64 MB for a WordPress multisite setup. Those defaults made sense when WordPress was primarily a blogging platform. Today, with full site editing, complex block layouts, and ecommerce functionality, 40 MB runs out before the page finishes loading. A single WooCommerce product page with variable pricing, inventory tracking, and shipping calculations can burn through 40 MB before it even renders the template.

The “Allowed memory size exhausted” error gives you a specific number in bytes, something like “Allowed memory size of 67108864 bytes exhausted.” That number (67,108,864 bytes) is exactly 64 MB, which tells you the current limit. Divide the byte count by 1,048,576 to get the megabyte value and you’ll know exactly where your ceiling sits.

Common triggers for hitting that ceiling include heavy plugins like WooCommerce or complex page builders, themes that bundle dozens of built-in modules, bulk imports of products or posts, and large image processing operations. Any action that forces PHP to hold more data in memory than the limit allows will crash with this error, and it can happen on the front end, in the admin dashboard, or during a scheduled background task like a cache rebuild or automated backup.

Before changing anything, you should know what your current limits actually are. WordPress has a built-in tool for this, and there are plugin-based options that give you even more detail about where your memory goes.

The fastest method is the Site Health screen built into WordPress core since version 5.2. Go to Tools, then Site Health, then click the Info tab. Scroll down to the “Server” section and look for two values: “PHP memory limit” (your host’s hard ceiling) and “WordPress memory limit” (the WP_MEMORY_LIMIT value). If these numbers are the same, it means WordPress is using the full allocation your host provides. If the WordPress value is lower, you have room to increase it without contacting your host.

For a more granular view, the Query Monitor plugin is the gold standard. It doesn’t just show your memory limits; it shows actual memory consumption per page load, broken down by component. Install it, load any page on your site, and check the admin bar where Query Monitor displays the peak memory usage for that request. If a page load consumed 38 MB out of a 40 MB limit, you can see exactly why the error fires on pages with one more plugin hook or a slightly larger database query. Query Monitor also flags slow queries and HTTP API calls that indirectly increase memory pressure.

If you can’t access the WordPress admin at all because the error crashes everything, you can still check through your hosting control panel. Most cPanel-based hosts show the PHP version and memory_limit under “Select PHP Version” or “MultiPHP INI Editor.” Alternatively, create a temporary file called info.php in your site root with just <?php phpinfo(); ?> inside it, load it in a browser, and search the output for “memory_limit.” Delete that file immediately afterward, because phpinfo() exposes sensitive server details that you don’t want publicly accessible.

Knowing both numbers, the PHP ceiling and the WordPress limit, tells you which change to make. If the WordPress limit is lower than the PHP limit, a wp-config.php edit is all you need. If they’re already equal and still too low, you’ll need to raise the PHP limit through .htaccess, php.ini, or your host’s control panel.

There are three methods, and you should try them in this order. Each one targets a different layer of the stack, and only one of them requires contacting your hosting provider.

Method 1: Edit wp-config.php (recommended first step). This is the WordPress-layer fix. Connect to your site via SFTP or your host’s file manager, open wp-config.php from the root directory, and find the line that reads /* That’s all, stop editing! Happy publishing. */ directly above it. Add these two lines right before that comment:

define(‘WP_MEMORY_LIMIT’, ‘256M’);

define(‘WP_MAX_MEMORY_LIMIT’, ‘512M’);

The first line sets the front-end memory to 256 MB, which handles most WordPress sites comfortably. The second line bumps the admin-side memory to 512 MB, giving your dashboard room for media uploads, bulk edits, and plugin operations that tend to be more memory-intensive than serving pages to visitors. Save the file and reload your site. If the error disappears, you’re done.

Method 2: Edit .htaccess (Apache servers only). If wp-config.php didn’t work, your host’s PHP memory_limit might be lower than what you requested. The .htaccess file can override some PHP settings on Apache servers. Open the .htaccess file in your WordPress root and add this line at the top, before the WordPress rewrite rules:

php_value memory_limit 256M

This tells Apache to set the PHP memory_limit to 256 MB for your site specifically. It won’t work on Nginx servers, and some shared hosting providers block php_value directives in .htaccess for security reasons. If your host runs Nginx, skip to Method 3 or contact them directly.

Method 3: Edit php.ini (server-level control). This method modifies the PHP configuration itself. On shared hosting, you can often create a local php.ini file in your WordPress root directory with a single line inside:

memory_limit = 256M

On hosts that use cPanel, look for the “MultiPHP INI Editor” tool, select your domain, and change the memory_limit value there. If you’re on a VPS or dedicated server, the main php.ini file sits at a path like /etc/php/8.2/fpm/php.ini. Edit it with SSH, change the memory_limit value, and restart PHP-FPM with sudo systemctl restart php8.2-fpm for the change to take effect. On Nginx servers, this is the only reliable method since .htaccess directives aren’t recognized by Nginx at all.

How much memory should you actually allocate? That depends on your site type. A straightforward blog with a handful of plugins runs fine on 128 MB. A business site with a page builder, contact forms, and 15 to 20 active plugins needs 256 MB. An ecommerce store built on WooCommerce or DigiCommerce should start at 256 MB and may need 512 MB during checkout and order processing. Large membership or LMS sites with concurrent users often need 512 MB or more. Start at 256 MB because it covers the vast majority of WordPress installations, and only go higher if monitoring shows you’re still bumping the ceiling.

If you’ve raised the limits in wp-config.php, tried .htaccess, created a local php.ini, and the error still appears, the problem isn’t the ceiling itself. Something on your site is consuming an unreasonable amount of memory, and throwing more RAM at it only delays the crash.

Start by contacting your hosting provider with a direct message: “I’m running WordPress and getting a fatal memory exhausted error. My current PHP memory_limit is [check Site Health and insert the value]. Can you increase it to 256 MB?” Most quality hosts handle this in minutes, and if they can’t or won’t raise it, that’s a strong signal you’ve outgrown your current hosting plan. Some shared hosting providers enforce a hard cap around 128 MB that no configuration file can override, and the only real fix is upgrading to a plan that allows more.

If the limit is already high enough and the error persists, you need to find the memory hog. The systematic approach is a plugin conflict test. Create a full backup first, then deactivate every plugin. If the error disappears, reactivate them one at a time, testing after each activation. The plugin that brings the error back is your culprit. You can then decide whether to replace it, report the issue to the plugin developer, or look for a lighter alternative.

A faster and more precise approach uses Query Monitor. With the plugin active, load the page that triggers the error (you might need to temporarily raise the memory limit high enough to let the page load). Query Monitor’s “Environment” panel shows peak memory usage, and the “Queries by Component” panel reveals which plugin or theme generated the most database queries. Heavy database usage often correlates directly with memory consumption. A plugin running 200 unoptimized database queries per page load will eat far more memory than one running 10 clean ones.

Don’t overlook the theme. Bloated themes packed with dozens of built-in features you never use can reserve significant memory just loading their frameworks. Switch temporarily to a default theme like Twenty Twenty-Five or a genuinely lightweight theme like DigiFlash to see if memory usage drops. If it does, your theme is part of the problem, and you’d benefit from a theme that loads only what it actually needs.

The same logic applies to page builders. Complex page builder layouts with many nested elements, custom widgets, and third-party addons increase memory consumption per page. Using native Gutenberg blocks instead of a heavy page builder framework reduces the memory footprint of every page load because WordPress doesn’t need to bootstrap an entire secondary rendering engine on top of its own block system. That’s not a theoretical benefit; it shows up clearly in Query Monitor’s memory readings.

The WordPress memory limit error sounds scarier than it is. For most sites, adding one line to wp-config.php solves it permanently. The key is knowing that WordPress has two separate limits (front-end and admin), that your host’s PHP ceiling overrides both, and that raising the limit is a fix for the symptom while finding memory-hungry plugins and themes is the fix for the cause.

Check your current limits through Site Health, raise them with the method that fits your hosting setup, and use Query Monitor if the problem comes back. A well-configured WordPress site on a reasonable hosting plan shouldn’t need more than 256 MB for standard operations. If it does, something is consuming memory it shouldn’t, and that something can be found and fixed.

The best long-term strategy is prevention: use a performance-first approach when choosing plugins and themes, audit your active plugins quarterly, and keep WordPress, PHP, and all extensions updated. Your server’s memory is a shared resource, and a lean site runs faster for everyone.