WordPress Memory Limit Exhausted: What It Means and the Fix

PHP gives every request a fixed allowance of memory and stops the request the moment it asks for more. The log then records "Allowed memory size of 268435456 bytes exhausted". The WordPress memory limit behind that message is really three settings kept in two places, which is why the fix most people find first, a line pasted into wp-config.php, works on some sites and does nothing on others.

Raising the limit brings a broken page back, and it is a fair first step. It is also how a real fault stays hidden for months. So there are two halves to this: raise the right setting, then find the code that wanted so much memory.

What the error line tells you

A full entry from the PHP log looks like this (the plugin name is a placeholder):

PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes) in /home/site/public_html/wp-content/plugins/example-export/class-export.php on line 212

The first number is the limit that applied to this request, in bytes. Translate it, because it tells you which setting was in force:

Bytes in the message	Limit
41943040	40M
67108864	64M
134217728	128M
268435456	256M
536870912	512M

The second number is the last request for memory that did not fit, not the total the code needed. A small figure means memory was already full and one more ordinary allocation tipped it over. A very large figure means the code tried to load one enormous thing at once: a file, an image or a query result.

The file and line show where PHP was standing when it ran out. That is a hint, not a verdict, because the code that filled the memory may have run earlier in the request. If the same plugin folder appears in the error every time, though, treat it as the main suspect. Our guide to reading WordPress fatal errors explains the rest of the entry.

Three settings share the name "memory limit"

Setting	Where it lives	What it governs	Default
memory_limit	php.ini, .user.ini or the hosting panel	Every PHP request on the account	128M in PHP itself, though hosts choose their own
WP_MEMORY_LIMIT	wp-config.php	Front-end requests	40M, or 64M on multisite
WP_MAX_MEMORY_LIMIT	wp-config.php	The dashboard, image processing and WP-Cron runs	256M

Three rules connect them, and they explain nearly every "I changed it and nothing happened" report:

• WordPress only raises the limit. If PHP's memory_limit is already higher than the WordPress constant, the PHP value stays in force.
• WordPress can raise it only when the host lets scripts change memory_limit at run time. Where the host has locked the value, both constants are ignored.
• The constants must be defined before wp-settings.php is loaded. A line added at the very bottom of wp-config.php arrives too late.

To see what is in effect, open Tools > Site Health > Info. The Server panel lists the PHP memory limit and the limit used for admin screens, and the WordPress Constants panel shows both constants. The wp-config.php handbook page documents the two constants.

Raise the WordPress memory limit in the right place

1. Download a copy of wp-config.php. A typing mistake in this file takes the whole site offline, and the copy is your way back.
2. Add the constants above the line that loads wp-settings.php. If the error came from the dashboard, the second line is the one that matters.

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

3. Reload the failing page and check Site Health again. If the figures did not move, the PHP setting is the ceiling.
4. Raise memory_limit in the PHP settings screen of the hosting panel. Where PHP runs as FastCGI or PHP-FPM, a .user.ini file in the site root with the line memory_limit = 256M does the same, after a delay of up to five minutes. On your own server, edit php.ini and reload the PHP service.
5. If the value still will not change, the plan has a hard cap. Ask the host what it is.

Two things to avoid. Do not put php_value memory_limit in .htaccess unless the server uses the Apache PHP module, because anywhere else that line produces a 500 error. And do not set the limit to -1, which means no limit: one runaway request can then take every other site and service on the machine down with it. The PHP manual describes the memory_limit directive in full.

Command-line PHP reads its own configuration, often with a higher limit or none. That is why an import can fail in the browser and succeed under WP-CLI, and why wp --info, which prints the php.ini in use, is worth running before you compare the two.

Why a bigger number can hide the problem

The limit applies to each request separately, and the server's memory is shared by every PHP worker running at that moment. Allow each of ten workers 512M and you have promised 5 GB. On a small server a busy minute then ends with processes being killed, and visitors see gateway errors and database failures that look unrelated to memory.

The second trap is code whose appetite grows with your data. A report that loads every order into an array works with a few hundred orders and fails with many thousands. Doubling the limit buys time, and the error comes back when the store has grown a little more. An ordinary page view on a healthy site needs a small fraction of 256M. If plain pages need most of it, something is wrong, and more memory only postpones finding out what.

Find the code that eats the memory

First pin down the request. The log entry and the access log at the same second tell you whether it was a public URL, an admin screen, admin-ajax.php, a REST call or wp-cron.php.

Then measure, on a staging copy if you have one. The Query Monitor plugin shows peak memory use for each page you load while logged in. Deactivate plugins in groups and reload the same page. Watch the peak memory figure and ignore whether the error itself comes and goes: the group whose removal makes the figure drop sharply holds the heavy plugin. The same approach finds slow code, as described in how to find the plugin slowing your site.

Background requests have no toolbar, so log them. This must-use plugin records every request that peaks above 128 MB:

<?php
// wp-content/mu-plugins/log-high-memory.php
add_action( 'shutdown', function () {
    $peak = memory_get_peak_usage( true ) / 1048576;
    if ( $peak > 128 ) {
        error_log( sprintf( 'High memory: %d MB on %s', $peak, $_SERVER['REQUEST_URI'] ?? 'cli' ) );
    }
} );

What usually turns up

• Queries with no limit, such as 'posts_per_page' => -1 on a large post type, or every user or order loaded for an export.
• Oversized autoloaded options. WordPress loads all of them on every request. Run wp option list --autoload=on --format=total_bytes to see the total. Site Health warns when it gets large.
• Image processing. A photo is held uncompressed while it is resized, so a large upload needs many times its file size.
• Imports and exports done in one request when they should run in batches.
• Recursion. A save_post callback that saves the post again calls itself until memory runs out.

Fixes that last

Most lasting fixes are a version of "handle less at a time". Fetch records in pages and ask only for what you need:

$ids = get_posts( array(
    'post_type'      => 'product',
    'posts_per_page' => 200,
    'paged'          => $page,
    'fields'         => 'ids',
    'no_found_rows'  => true,
) );

Move long jobs out of web requests into a background queue or a WP-CLI command. Keep logs and large caches out of autoloaded options. Resize huge images before upload. And when a third-party plugin is the cause and its author will not fix it, replace it. Back up before any of these changes, and try them on staging first.

When raising the limit stops being the answer

Raising the limit once, to a value your host supports, is ordinary housekeeping. Treat it as a symptom when you have raised it twice, when web requests need more than 512M, or when the error returns as the data grows. At that point the work is diagnosis: profiling the request, reading the queries and rewriting the part that loads too much. Our WordPress maintenance team does this as a matter of routine, with performance optimization for sites where memory is one sign of a larger load problem, and custom plugin development when the hungry code is your own and needs rebuilding.

Frequently asked questions

What should the WordPress memory limit be set to?

There is no universal figure. 256M is a common ceiling for stores and sites with page builders, and smaller sites run well on less. What matters more than the number is that normal pages stay far below it. Never set it to unlimited.

I added WP_MEMORY_LIMIT and nothing changed. Why?

Usually for one of three reasons. The host has locked memory_limit so scripts cannot raise it, the line sits below the point where wp-settings.php is loaded, or the error happens in the dashboard, where WP_MAX_MEMORY_LIMIT applies.

Does a higher memory limit make WordPress faster?

No. The limit is a ceiling, not an allocation. A page that needs 60 MB uses 60 MB whether the ceiling is 128M or 512M. Speed comes from caching, fewer queries and lighter code.

Why does the error only appear when I upload images?

Because resizing is the heaviest thing most sites do. The image is unpacked into memory at its full pixel dimensions, and a resized copy is built for every registered image size. Scale very large photos down before uploading, or raise WP_MAX_MEMORY_LIMIT, which is the setting that covers image processing.