How to Fix the WordPress Memory Exhausted Fatal Error

The "Allowed memory size exhausted" fatal error is one of the most common ways a WordPress site breaks on any host, and it looks scarier than it is. This Ultra Web Hosting guide explains exactly what the error means, how to confirm it really is a memory problem, and the correct order in which to raise the limits. Just as important, it covers when raising the number is the wrong move and you should instead hunt down the plugin or query that is eating all your memory in the first place.

01. What the Memory Exhausted Error Actually Means

WordPress runs on PHP, and every PHP process on the server is allowed to use only so much memory before it is killed. When a page load tries to use more than that ceiling, PHP stops it dead and writes a message that reads something like this:

Fatal error: Allowed memory size of 268435456 bytes exhausted
(tried to allocate 20480 bytes) in
/home/youracct/public_html/wp-includes/class-wp-query.php on line 3456

The number 268435456 is bytes, which works out to 256M. It means the process asked for a little more memory, the account or server said no, and the request was killed mid-run. The file and line at the end tell you where PHP happened to be when it ran out, but that is rarely the true cause. It is simply where the last straw landed. This most often happens on a heavy plugin operation, a large import or backup, a bloated wp-admin page such as the plugins or updates screen, or a WooCommerce store rebuilding its catalog.

02. How the Error Shows Up on Your Site

Depending on your WordPress version and debug settings, a memory exhaustion event wears one of three faces:

• The raw fatal error printed on a white background, exactly like the block above. This happens when debug display is on or the error is thrown before WordPress can catch it.
• A blank white page with no text at all. PHP hit the ceiling and died, and display of errors is off, so you get nothing. This is the classic White Screen of Death. Our guide "How to Fix the WordPress White Screen of Death" walks through it, and memory exhaustion is one of its top causes.
• The generic "There has been a critical error on this website" message. Modern WordPress traps the fatal error and shows this friendly page instead of a blank screen, usually with an email to the admin address. Our guide "How to Fix There Has Been a Critical Error on This Website" covers reading that email, which frequently points straight at a memory limit.

All three can be the same underlying memory problem. The only way to be sure is to read the actual error, which is the next section.

03. Confirm It Is a Memory Error, Not Something Else

Before changing any limits, confirm memory is genuinely the problem. A white screen or critical error can also come from a PHP syntax error, a broken plugin update, or the wrong PHP version. Turn on the debug log and read it.

Add these lines to wp-config.php, just above the line that reads /* That's all, stop editing! Happy publishing. */:

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

1. Edit wp-config.php in the root of your WordPress install, using cPanel File Manager or FTP.
2. Add the three lines above, then save.
3. Reload the page that breaks so the error is logged.
4. Open wp-content/debug.log and read the most recent entry. A memory problem reads PHP Fatal error: Allowed memory size of ... bytes exhausted.
5. When you are done, set WP_DEBUG back to false so errors are not logged in the open on a live site.

04. The Layered Limits: PHP vs WordPress

There is more than one memory limit in play, and understanding how they stack is the key to fixing this cleanly. Two layers matter.

The PHP limit (memory_limit) is set at the server and account level. It is the true hard ceiling. No WordPress setting can raise your effective memory above what PHP allows, and PHP itself is capped by what your hosting plan permits.

The WordPress limits (WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT) are WordPress asking PHP for a working budget. WP_MEMORY_LIMIT applies to the front end and defaults to 40M. WP_MAX_MEMORY_LIMIT applies to the admin area and defaults to 256M, because admin tasks are heavier. WordPress uses these to call PHP's own memory function, but it can only ask for what PHP is willing to give.

The practical upshot: raising the WordPress values does nothing if PHP is already lower. If WP_MEMORY_LIMIT is 256M but PHP memory_limit is 128M, you still cap at 128M. Fix them in the right order, WordPress first because it is the easiest, then PHP if that is not enough.

05. Method 1: Raise the Limit in wp-config.php

This is the first thing to try and it fixes the majority of cases. You are telling WordPress to request more memory from PHP for both the front end and the admin area.

1. Open wp-config.php in the root of your WordPress install with cPanel File Manager or FTP.
2. Add the two lines below above the line that sets the table prefix ($table_prefix = 'wp_';). Placement matters: defines after WordPress has loaded are ignored.
3. Save the file and reload the page that was breaking.

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

$table_prefix = 'wp_';

Here WP_MEMORY_LIMIT raises the front-end budget to 256M, and WP_MAX_MEMORY_LIMIT raises the admin budget to 512M for heavier tasks like imports and updates. These are sensible values for a busy site. If the error was in wp-admin, the second line is the one doing the work.

06. Method 2: Raise PHP memory_limit in cPanel

If the wp-config.php change did not help, PHP itself is the ceiling and you need to raise memory_limit at the account level. On Ultra Web Hosting you do this in cPanel, no ticket required.

1. Log in to cPanel and open MultiPHP INI Editor (under the Software section).
2. In the Basic Mode tab, choose the domain for your WordPress site from the dropdown.
3. Find memory_limit and set it to a sensible value such as 256M or 512M.
4. Click Apply. The change takes effect on the next page load.
5. Reload the page that was breaking to confirm the error is gone.

While you are in cPanel, make sure the domain is running a current, supported PHP version, since an old version has a lower default and other limits. See Change PHP Version for how to select it, and Changing Maximum Upload Size and PHP Limits for the related settings that often need raising at the same time, such as upload_max_filesize and max_execution_time.

07. Alternative: php.ini and .user.ini

If you prefer editing files, or you want the setting to travel with the site, you can set memory_limit in a php.ini or .user.ini file in your WordPress root instead of the cPanel editor. Both do the same job as the MultiPHP INI Editor and are still bound by your plan ceiling.

Create or edit a file named .user.ini in public_html (or your WordPress root) with this single line:

memory_limit = 256M

The .user.ini file is the right choice on most modern PHP handlers and applies to that directory and below. A traditional php.ini works too on some configurations. Changes to these files can take a few minutes to register because PHP caches them, so wait before deciding it did not work.

08. The Caveat: Find the Culprit, Do Not Just Raise the Number

Here is the part most tutorials leave out. A normal WordPress page, even a busy one with a page builder and a dozen plugins, should render comfortably in 128M to 256M. If a single ordinary page keeps demanding 512M or more, that is not a limit you need to raise. It is a symptom that something is wrong: a bloated or badly written plugin, an infinite loop, an unoptimized database query looping over thousands of rows, or a theme loading its entire media library on every request.

Raising the ceiling to 1024M to silence the error just moves the wall back a few feet. The bad code keeps growing, and next week the error returns at the higher number. Worse, a runaway process now eats a gigabyte of your account's resources every time it runs, which drags down the rest of your site and can trip your account resource limits (Section 09).

To find the culprit, use the standard plugin bisection method:

1. Deactivate all plugins. If you can reach wp-admin, do it from the Plugins screen. If the admin is down, rename the wp-content/plugins folder to plugins-off using File Manager, which deactivates them all at once.
2. Confirm the error is gone. If the page now loads within a normal limit, one of the plugins is the cause.
3. Reactivate one plugin at a time, reloading the problem page after each. When the memory error returns, the plugin you just enabled is your culprit.
4. Decide what to do with it: update it, replace it with a lighter alternative, or contact its developer. Do not leave it running while masking the symptom with a huge limit.
5. Check the theme too. Temporarily switch to a default theme like Twenty Twenty-Four to rule the theme out.

Once the site loads, keep it lean so this does not recur. Caching, image optimization, and a trimmed plugin list all cut memory use per request. See How to Optimize WordPress Performance for the full checklist.

09. Memory Limit vs Resource Limit (508/503)

It is worth being clear that a PHP memory fatal is not the same thing as an account resource limit, even though both can take a site down. They are different systems and they have different fixes.

• A PHP memory fatal ("Allowed memory size exhausted") is a single request exceeding memory_limit. It is fixed by the methods in this guide: raise the limit or, better, fix what is eating it.
• An account resource limit shows as a 508 Resource Limit Is Reached or sometimes a 503, and it means your whole account has hit its allowance for CPU, memory, entry processes, or I/O across all requests at once. This is throttling at the account level, not a single page running out of memory.

They are related in that a memory-hungry plugin causing repeated fatals will also drive your account toward its resource ceiling, so fixing the memory leak helps both. But if you are seeing 508 or 503 errors specifically, that is a separate topic. Read Resource Limit Reached (508 and 503 Errors) for how to diagnose and resolve those, including when the honest answer is that a growing site has outgrown its plan and it is time to upgrade.

Quick Recap: Fixing Memory Exhausted in Six Steps

If you only do six things from this guide, do these:

1. Confirm it is memory by reading wp-content/debug.log for "Allowed memory size ... exhausted" rather than guessing.
2. Add the WordPress defines to wp-config.php above the table prefix line: WP_MEMORY_LIMIT at 256M and WP_MAX_MEMORY_LIMIT at 512M.
3. Raise PHP memory_limit in cPanel MultiPHP INI Editor if the WordPress change was not enough, remembering your plan has a hard ceiling.
4. Do not endlessly raise the number. A normal page should run in 128M to 256M, so a page needing far more has a real bug.
5. Find the culprit by deactivating all plugins and reactivating one at a time until the error returns, then fix or replace that plugin.
6. Know the difference between a memory fatal and a 508/503 resource limit, and optimize or upgrade when the site has genuinely outgrown the plan.

Last updated July 2026 · Browse all WordPress articles