Memory Exhausted in WordPress? Fix It Safely

You open your site and find a white screen, or a wall of text that begins with "Fatal error: Allowed memory size of 268435456 bytes exhausted." Sometimes WordPress shows only the vague "There has been a critical error on this website" message instead. Either way, the cause is the same. A PHP process asked for more memory than the server allows it to use, and the server stopped it.

The good news is that this is one of the most fixable WordPress errors. The less obvious news is that the popular fix, pasting one line into wp-config.php, fails on a lot of sites and nobody explains why. This guide covers the fix, the reasons it sometimes does nothing, and how to find the plugin or task that is actually eating the memory so the error does not come back.

What the error actually means

WordPress, your theme and every plugin run as PHP code. Each time someone loads a page, saves a post or runs an import, the server starts a PHP process and gives it a fixed amount of memory. If the work needs more than that amount, PHP stops with a fatal error. Nothing is "broken" in the sense of lost files. The process simply hit its ceiling.

That ceiling is called the PHP memory limit. Three different layers can set it, and they do not always agree:

• The server or host. Your hosting plan sets a default in PHP's configuration, often 128M or 256M on shared plans and sometimes 64M or lower on bargain plans.
• WordPress itself. WordPress can ask for a specific amount through constants in wp-config.php, but it can only ask for what the server allows.
• Per-folder overrides. Files such as .htaccess or .user.ini can change the value for one site on a server.

Understanding that three-layer picture saves a lot of wasted effort later, because the real fix is often "change it at the right layer," not "type a bigger number."

Decoding the number in the message

The error reports the limit in bytes, which is hard to read. Here is the conversion for the numbers you are most likely to see:

The second number, "tried to allocate X bytes," shows how much extra memory the task asked for at the moment it failed. A small value (a few hundred kilobytes) means the site was already nearly full and one more small request tipped it over. A large value (tens of megabytes) usually means a single heavy task, such as resizing a huge image or loading a giant export.

The end of the message also names a file and line, for example /wp-content/plugins/some-plugin/includes/file.php on line 214. Keep that path in mind. It is the best clue you will get, and we will use it later.

Back up before you edit anything

You will need file access to make these edits. That means your host's File Manager, SFTP, or SSH. If you are locked out of the dashboard, this is the route to use anyway.

Fix 1: raise the limit in wp-config.php

This is the quickest fix and works on many hosts. Open wp-config.php in your site's root folder and add the following lines above the comment that says "That's all, stop editing":

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

What each line does:

• WP_MEMORY_LIMIT is the memory WordPress requests for normal front-end and general work.
• WP_MAX_MEMORY_LIMIT is a higher ceiling WordPress uses for heavier admin tasks, such as image processing and updates.

Save the file, then reload the page that was failing. If the error is gone, you are done with the immediate problem. Skip ahead to the section on finding the culprit, because a site that needed this change may have a plugin worth looking at.

If the error remains, or the number in the message did not change, the server is overriding WordPress. That is the situation Fix 2 handles.

Fix 2: change php.ini or your hosting panel

When the host sets the limit, WordPress cannot raise it past that value. You then need to change the value where it is defined. There are three common ways, from easiest to most technical.

Use your hosting control panel

Most hosts expose the setting in a menu. In cPanel it is usually called "MultiPHP INI Editor" or "Select PHP Version" with an options tab. Other panels place it under "PHP Settings," "PHP Configuration" or "Advanced." Look for memory_limit, change it to 256M, and save. This is the safest route because the panel validates the value for you.

Edit php.ini or .user.ini yourself

If you have a php.ini file in your site's root, or can create one, add or change this line:

memory_limit = 256M

On hosts that run PHP through FastCGI or PHP-FPM, a per-site file named .user.ini is often the one that is read instead. The line is identical. Be aware that these files can take a few minutes to be picked up because PHP caches them briefly.

Ask your host

If none of that is available, send support a direct message: "Please raise the PHP memory_limit to 256M for my account." On a managed plan this is a thirty-second request. If they refuse because the plan caps it, you have learned something important: the plan itself is too small for the site. Our guide to WooCommerce hosting costs shows what better tiers typically include.

Fix 3: the .htaccess method

On Apache servers that run PHP as a module, you can set the value in the .htaccess file in your site root:

php_value memory_limit 256M

Treat this one with caution. If your server runs PHP through PHP-FPM or FastCGI, the php_value directive is not allowed and the site will answer with a 500 error as soon as you save. If that happens, remove the line immediately. Our WordPress 500 error guide covers recovery. Because of this risk, try Fix 1 and Fix 2 first, and use this method only when you know your server setup.

Why your change did nothing

This is the part most tutorials skip. If you changed a setting and still see the same number in the error, work through these causes in order.

1. The host's cap wins. WordPress asks for 256M but the server only allows 128M, so 128M is what you get. Only a change at the server or panel level fixes this.
2. You edited the wrong file. Staging copies, subfolder installs and add-on domains each have their own wp-config.php. Confirm that the file you edited belongs to the site that is failing.
3. The line is in the wrong place. If it sits below the "stop editing" comment, WordPress may never read it in time.
4. Cache is serving the old error. Clear your page cache, your CDN cache and any server-level cache, then test in a private window.
5. A .user.ini delay. Wait five to ten minutes and test again.
6. A different PHP version is active. Some panels keep separate settings for each PHP version. Make sure you edited the version your site actually runs.

To confirm what PHP really sees, go to Tools, then Site Health, then the Info tab, and open the Server section. It lists the PHP memory limit in effect. If it shows 128M after you set 256M, the change did not reach the right layer.

Find what is really using the memory

Raising the limit treats the symptom. If a site needed 512M to load a basic page, something is wrong, and the error will return as content grows. Here is how to find the real cause.

Step 1: read the file path in the error

The message ends with a path. The folder name right after /wp-content/plugins/ or /wp-content/themes/ names the code that was running when memory ran out. That code is not always the guilty party, since it may just be the last straw, but it is the best first suspect.

Step 2: turn on the debug log

If you cannot see the error on screen, log it to a file. Add this to wp-config.php above the "stop editing" line:

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

Errors are then written to wp-content/debug.log without showing visitors anything. Repeat the action that fails, read the newest lines, and note which plugin path appears. Set WP_DEBUG back to false when you are done, and delete the log, because it can contain file paths you do not want public.

Step 3: isolate by deactivating

If you can reach the dashboard, deactivate the suspect plugin and retry. If you cannot, rename its folder through SFTP, for example from some-plugin to some-plugin-off. WordPress will deactivate it automatically. For a systematic approach when several plugins are involved, follow our plugin conflict troubleshooting guide.

Step 4: match the symptom to a cause

Step 5: measure instead of guessing

A free diagnostic plugin such as Query Monitor shows memory used per page and which plugin accounts for it. Install it on a staging copy, load the heavy page, and read the memory figure. If one plugin dominates, you have your answer.

How much memory is enough

There is no official number, but these ranges are a sensible starting point based on common practice:

More is not automatically better. Setting an enormous value hides a leaky plugin instead of exposing it, and on shared hosting one runaway process can slow every other site on the server. Aim for the smallest value that runs the site comfortably, then investigate anything that needs more.

Keeping it from coming back

• Audit your plugins. Delete anything inactive or duplicated. Fewer plugins means less code loaded on every request.
• Keep everything updated. Many memory leaks are fixed in later plugin releases. A tidy update routine is part of any WordPress maintenance plan.
• Optimize images before upload. Oversized images are one of the most common memory spikes. Our WordPress speed optimization guide covers image and caching practices that also lower memory use.
• Use object caching where your host offers it. It reduces repeated database work on busy stores.
• Test updates on staging. A new plugin version that is hungrier than the last one is much easier to catch before it goes live.
• Watch your plan. If a growing store keeps outrunning its hosting, the honest fix is a better plan, not another config tweak.

If the memory error arrived together with a blank page and no message at all, the cause may be broader than memory. Our guide to the WordPress white screen and critical error walks through the other common triggers, and the login loop guide helps if the failure is blocking wp-admin.

When to get a developer involved

You can handle a basic limit increase yourself. Bring in a WordPress developer when:

• You raised the limit and the error returns within days.
• The debug log points to a custom plugin or theme code, not a well-known plugin.
• A live store is losing orders while the error persists.
• You are not comfortable editing server configuration files on a live site.
• You suspect the memory use is a symptom of something larger, such as malware or a bad import.

A developer can profile the site, find the exact function using the memory, and fix it at the source, rather than leaving you with a bigger limit and the same underlying problem. This is usually a short job when the cause is a single plugin or setting.

FAQ

Is it safe to increase the PHP memory limit?

Yes, within reason. Moving from 64M or 128M up to 256M is routine and low risk. The danger is setting an extreme value on shared hosting, which can slow your site and your neighbors. Raise it in steps and fix the underlying cause if you keep needing more.

What is the default WordPress memory limit?

WordPress sets its own default request, which is modest, and it will try to raise a low server limit up to that default. It cannot go beyond what the host allows. That is why the real number you get is decided by your hosting plan, not by WordPress alone.

I added the line to wp-config.php and nothing changed. Why?

Almost always because the server limit is lower than the value you requested, or because the line sits below the "stop editing" comment. Check the limit shown in Site Health, then change it in your hosting panel or ask support. The "Why your change did nothing" section above lists every common cause.

Can a plugin cause this error even if the limit seems high?

Yes. A plugin with a loop bug or one that loads a huge dataset can exhaust any limit. If the error appears even at 512M, stop raising the number and use the debug log to identify the plugin.

Why do I only see the error in the admin area?

Admin tasks, such as image processing, updates and imports, need more memory than front-end page views, so the admin hits the ceiling first. This is the reason WordPress has a separate higher limit for admin tasks.

Will increasing memory fix a slow website?

Not by itself. Memory prevents crashes, but it does not make pages load faster. Speed comes from caching, lighter plugins, optimized images and decent hosting.

How much does it cost to have someone fix this?

If the cause is a straightforward limit or one problem plugin, it is typically a short, small job. Costs rise when the fix involves custom code, a hacked site or a store that needs a hosting move. A clear error message and the debug log let a developer quote accurately.