Resolving WordPress Fatal Error: Out of Memory

Your site worked fine yesterday. Today it returns a blank screen and one line in the log: allowed memory size exhausted.

The WordPress fatal error out of memory happens when one PHP request asks for more RAM than the memorylimit directive allows. PHP kills the process mid-render.

Raising the number in wp-config.php fixes maybe half of these cases. The other half need a different approach.

What follows covers:

• What the byte values in the error actually mean
• Every method for raising the PHP memory limit, ranked by reliability
• How to find the plugin burning the memory
• Which lookalike errors have nothing to do with RAM

Recovery included, for when wp-admin will not load at all.

What Is the WordPress Fatal Error: Out of Memory

The WordPress fatal error out of memory is a PHP failure that halts script execution when a single request tries to allocate more RAM than the memorylimit directive permits. PHP kills the process, prints the error, and the page stops rendering mid-request.

The full string looks like this:

“ Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 262144 bytes) in /home/site/publichtml/wp-includes/wp-db.php on line 2056 `

Those byte values throw people off. They are just the memory limit expressed in raw bytes.

Key point most people miss: the limit applies per PHP process, not per site.

Ten visitors hitting the site at once means ten separate processes, each with its own 256M ceiling. The error fires when one of them blows past that ceiling on its own.

What “Allowed Memory Size Exhausted” Means in PHP

memorylimit is a PHP directive, not a WordPress setting. WordPress can only request memory inside whatever PHP has already been told to allow.

PHP tracks allocation per script execution. Once the running total crosses the threshold, PHP raises a fatal EERROR and stops. No graceful degradation, no partial page.

The result on screen is either a blank white screen with no output at all or the generic “There has been a critical error on this website” notice, depending on whether displayerrors is on.

Which File and Line Number the Error Points To

The file path in the error is where PHP ran out of room, not where the problem started.

A crash in wp-db.php or wp-includes/class-wp-hook.php almost never means WordPress core is broken. Core was simply holding the bag when the last allocation failed.

Look higher up the stack trace instead. If any frame contains /wp-content/plugins/some-plugin/, that folder name is your first suspect.

Where the error surfaces:

• Browser output, if displayerrors is enabled

• /wp-content/debug.log, if WPDEBUGLOG is defined

• The server-side log your host writes PHP failures to
• The recovery mode email sent to the admin address

What Causes Memory Exhaustion in WordPress

Memory exhaustion happens when one PHP request allocates more than the configured limit. Three factors drive it: plugin and theme code that loads too much at once, a server default set too low for the stack, and data volume that quietly multiplies every query result.

Plugin and Theme Code as the Primary Cause

Every active plugin contributes to baseline memory before any page-specific logic runs.

Dev4Press data from 2024 puts an average install of 20 active plugins at a 48-64MB baseline. Push that to 40 plugins and the baseline roughly doubles.

Most WordPress sites run 12 to 15 plugins on average, according to WPCoupons 2026 data. Elementor alone sits on 31.2% of live WordPress sites (W3Techs, 2026), and it is one of the heavier consumers in the ecosystem.

The specific code patterns that blow up memory:

• WPQuery with postsperpage => -1 loading every post object into an array

• Infinite or recursive loops inside init, thecontent, or savepost hooks

• Two plugins registering conflicting filters that each re-trigger the other

Server Defaults That Set the Limit Too Low

WordPress core ships with WPMEMORYLIMIT at 40MB for single-site installs and 64MB for multisite (Contabo, 2024).

Shared hosts usually override that with a php.ini value somewhere between 64M and 256M. Entry-level plans still land at 64M more often than they should.

A stack of Elementor plus WooCommerce plus an SEO plugin does not fit in 64M. Elementor’s own documentation asks for 256MB minimum and 512MB recommended, and the memory exhausted failure shows up on the first template import.

Data Volume as a Silent Multiplier

Image processing is the worst offender because GD decompresses the entire file into a raw bitmap before touching a single pixel.

The formula: width x height x 3 bytes for a standard 24-bit JPEG.

A 4042 x 4992 photo works out to roughly 57.7MB of RAM for one thumbnail operation, even though the JPEG on disk is only 1.4MB.

Autoloaded options are the quieter multiplier. WordPress pulls every row flagged autoload = yes from wpoptions on every single request, including AJAX calls and REST hits.

WPMU DEV recommends keeping that payload under 800KB. WP Multitool found an average of 4.2MB across 50+ audited sites, with two-year-old WooCommerce stores regularly hitting 3-8MB.

How Much PHP Memory WordPress Requires

WordPress.org lists 64MB as the technical floor and 256MB as the recommended memorylimit for real-world installs. Page builders, ecommerce, and membership stacks need 512MB. Anything above 512MB is a diagnostic ceiling, not a production target.

Those Elementor figures come straight from Elementor’s published system requirements, not from guesswork.

Two WordPress constants matter here:

• WPMEMORYLIMIT: front-end ceiling, defaults to 40M

• WPMAXMEMORYLIMIT: admin and cron ceiling, defaults to 256M

Setting 1024M because it seems safer is a mistake. Memory limit multiplied by worker count is what your server actually has to survive.

Hostney’s 2026 breakdown puts a typical WordPress worker at 40-80MB of real resident memory, with WooCommerce plus a builder pushing past 100MB. DCHost ran the math: 20 workers at 256M each is a theoretical 5GB, which does not fit on a 4GB VPS.

How to Increase the PHP Memory Limit in WordPress

Six methods raise the PHP memory limit, ranked here by how reliably they work: php.ini, the host control panel, wp-config.php, .htaccess, iniset in a must-use plugin, and a support ticket. The server-level value always wins over anything WordPress declares.

Editing wp-config.php with WPMEMORYLIMIT

Add these two lines above the / That’s all, stop editing! / comment:

` define( 'WPMEMORYLIMIT', '256M' ); define( 'WPMAXMEMORYLIMIT', '512M' ); `

Place them below that comment and WordPress ignores them completely. Nothing annoys me more than watching someone paste a correct snippet into the wrong half of the file and conclude the fix does not work.

This method raises WordPress’s internal request, not the PHP ceiling. If php.ini caps you at 128M, declaring 256M here gets you 128M.

Raising memorylimit in php.ini

The only method that changes the actual ceiling.

` memorylimit = 256M `

Finding the file is the hard part, since the path differs by stack and hosting type. Details on locating the php.ini file on a WordPress install vary between cPanel, VPS, and managed environments.

On PHP-FPM setups, the pool config at /etc/php/8.3/fpm/pool.d/www.conf overrides php.ini anyway. Restart PHP-FPM after any edit or nothing changes.

Using .htaccess on Apache

` phpvalue memorylimit 256M `

Works on Apache with modphp. Does nothing on Nginx, and throws a 500 error on servers running PHP-FPM because phpvalue is not a recognized directive there.

LiteSpeed handles it, mostly. If the site white-screens right after the edit, pull the line back out via SFTP.

Setting the Limit Through cPanel, Plesk, or the Host Dashboard

Fastest route for anyone on shared hosting.

cPanel: MultiPHP INI Editor, or Select PHP Version, then Options.

Plesk: Websites & Domains, then PHP Settings.

Cloudways: Server Settings & Packages, then Basic.

Managed hosts like Kinsta and WP Engine set 256M or higher by default and lock the panel. SiteGround exposes it through Site Tools.

Changing the Limit with iniset in a Must-Use Plugin

Last resort before calling support. Drop a file at /wp-content/mu-plugins/memory.php:

` <?php iniset( 'memorylimit', '256M' ); `

A must-use plugin loads before regular plugins, which is why this beats adding the same line to your theme’s functions.php file. Theme functions load too late to prevent an early crash.

iniset fails silently when the directive is locked as PHPINISYSTEM, or when the Suhosin patch is active with suhosin.memorylimit set.

When to Ask the Host Instead

Three signals mean the host controls the value and you do not:

• Site Health still reports the old number after every method above
• phpinfo shows a Master Value you cannot override
• The .htaccess edit triggers a server-side 500 response

Ask for a specific number. “Please raise memorylimit to 256M” gets resolved. “My site keeps crashing” gets a canned reply about clearing your cache.

How Server Configuration Overrides WordPress Memory Settings

PHP reads configuration in a fixed order, and later layers override earlier ones only when the directive scope allows it. The server php.ini and the PHP-FPM pool config sit above WordPress in that chain, so a wp-config.php value can never exceed them.

Directive scope decides everything. memorylimit is PHPINIALL, so runtime changes are technically legal. Hosts routinely lock it anyway.

Three environment-specific gotchas worth knowing:

• Suhosin: suhosin.memorylimit caps iniset independently of PHP's own value

• Nginx: ignores .htaccess entirely, so the file might as well not exist
• CloudLinux LVE: enforces a per-account memory cap above PHP, which is why shared hosting throws 508 errors instead of clean PHP fatals

Managed platforms handle this differently. Kinsta, WP Engine, and Cloudways set 256M or higher at the platform level and treat wp-config declarations as advisory.

How to Verify the New Memory Limit Took Effect

Check the applied value through Tools, then Site Health, then Info, then the Server panel. This reports what PHP actually enforces, not what wp-config.php requested. WP-CLI and phpinfo give the same answer from the command line and the browser.

Fastest check, no plugins needed:

Site Health has shipped with core since WordPress 5.2. The Server panel lists PHP memory limit alongside PHP version, max execution time, and upload max filesize.

From SSH, WP-CLI answers in one line:

` wp eval 'echo iniget("memorylimit");' `

For the full picture, drop a temporary phpinfo() file in the web root and read the memorylimit row. Local Value is what applies to this directory. Master Value is the server default, and a gap between the two means your override landed.

Delete that file immediately after reading it. Leaving phpinfo publicly reachable hands attackers a full map of your stack.

To measure real consumption rather than the ceiling, log peak usage at the end of a request:

` errorlog( memorygetpeakusage( true ) / 1048576 . ' MB' ); `

Query Monitor shows the same number per request in the admin bar, broken down by hook. Enabling PHP error output on a WordPress install first makes the results readable instead of silent.

One step people skip: restart PHP-FPM and flush OPcache after editing php.ini. Without a restart the old value stays cached and you will swear the edit did nothing.

How to Regain Access to a Site Locked Out by the Memory Error

Recovery mode restores admin access without FTP. WordPress emails a one-time tokenized link to the administration email address, pauses the extension that triggered the fatal error, and loads wp-admin normally. If the email never arrives, rename the plugins folder over SFTP.

Recovery mode shipped in WordPress 5.2 on May 7, 2019, handled by wp-includes/class-wp-fatal-error-handler.php. Before that, a fatal error meant a white screen and nothing else.

It only triggers on a regular page load. Crashes during cron or background tasks produce no email at all.

Using the Recovery Mode Email

Look for a subject line reading “Your Site is Experiencing a Technical Issue” in the inbox tied to Settings, then General, then Administration Email Address.

The message names the offending plugin or theme and includes the error log excerpt. That is usually the whole diagnosis, handed to you for free.

If that mailbox is dead, redirect the notification by adding this to wp-config.php before triggering another load:

` define( 'RECOVERYMODEEMAIL', 'you@yourdomain.com' ); `

Renaming Folders Over SFTP

The blunt instrument, and the one that always works.

• Rename /wp-content/plugins to /wp-content/plugins-off

• Load wp-admin, which now runs with zero plugins active
• Rename the folder back, then reactivate plugins one at a time

Same trick works for a broken theme. Rename the active theme folder and WordPress falls back to the most recent default, currently Twenty Twenty-Five.

Deactivating this way is also the standard escape hatch for a plugin update that breaks the site, memory-related or not.

Deactivating Through WP-CLI

Faster than SFTP if you have SSH, because WP-CLI bypasses the front-end bootstrap that keeps crashing.

` wp plugin deactivate --all --skip-plugins --skip-themes wp plugin activate woocommerce --skip-themes `

–skip-plugins is the flag that matters. Without it, WP-CLI loads the same broken code and dies the same way.

Capturing the Log Before You Change Anything

Turn on logging first. Deactivating everything erases the evidence, and then you are guessing.

` define( 'WPDEBUG', true ); define( 'WPDEBUGLOG', true ); define( 'WPDEBUGDISPLAY', false ); `

Reload the page, then read /wp-content/debug.log. The file path in the last fatal entry names the folder to disable.

Set WPDEBUGDISPLAY to false on any live site. Public stack traces expose file paths, and a visible critical error notice on your WordPress site is bad enough without the server layout attached.

How to Identify the Plugin or Theme Consuming the Memory

Read the file path in the stack trace first, then confirm with a profiler. Query Monitor reports peak memory per request and attributes queries to individual components. Health Check & Troubleshooting isolates plugins for your session only, leaving visitors on the working site.

Reading the Stack Trace

The folder name in the path is the answer.

A trace ending in /wp-content/plugins/some-slider/includes/query.php names the plugin outright. A trace pointing at /wp-content/themes/ means you are chasing a theme-level failure rather than a plugin.

Core paths lie. wp-db.php, class-wp-hook.php, and plugin.php show up constantly because they sit at the bottom of every call chain.

Query Monitor attributes every database query to its component (core, theme, or a specific plugin), which is the fastest way to connect a crash to code you did not write.

Isolating Plugins Without Taking the Site Offline

Health Check & Troubleshooting disables plugins for your browser session alone. Other visitors keep seeing the working site while you break things.

Binary search beats one-by-one testing. With 24 plugins, halving the set finds the culprit in 5 rounds instead of 24.

• Disable half, test, note which half breaks
• Split the failing half again
• Repeat until one plugin remains

Query Monitor itself adds roughly 10% to PHP memory consumption and 10-100ms of page generation time, according to Oxygen’s 2026 review. On a site already at the ceiling, the debugger can trigger the very fatal error you are hunting.

Run this query in phpMyAdmin before blaming any plugin:

` SELECT optionname, LENGTH(optionvalue) AS size FROM wpoptions WHERE autoload = 'yes' ORDER BY size DESC LIMIT 20; `

Which WordPress Operations Trigger Memory Spikes

Bulk operations consume memory faster than normal page loads because they process many objects inside a single PHP request. Imports, image regeneration, backups, and page builder editor sessions account for most crashes on sites that otherwise run fine all week.

The heavy hitters, roughly in order of how often they break things:

• WXR imports: the WordPress Importer builds every post object in memory before writing
• Thumbnail regeneration: each source file decompresses to a raw bitmap, one after another
• WooCommerce CSV product imports and order exports: thousands of rows in a single array
• Full-site backups: UpdraftPlus, Duplicator, and All-in-One WP Migration all archive inside PHP
• Page builder editor loads: Elementor asks for 512MB and calls 768MB best-case

Media work is where most people meet the error for the first time. A failed thumbnail leaves the file in the database with no derivative sizes, which is why the symptom often reads as an upload that refuses to go through rather than a memory problem.

wp-cron is the sneaky one.

WP-Cron fires on page load, not on a schedule. AsiaGB’s 2026 breakdown puts it plainly: a site taking 1,000 visits per hour can trigger wp-cron.php 1,000 times in that hour.

Stack a backup job, a WooCommerce stock sync, and a marketing automation on the same tick and one unlucky visitor’s request carries all three.

Large REST responses and unpaginated admin list tables round out the list. Importing a demo package is the classic trigger for media that fails partway through the import, since attachments and their thumbnails process in the same request.

How to Fix Memory Errors Without Raising the Limit

Raising memorylimit treats the symptom. When a plugin loops or a query returns 40,000 rows, 512M fills as fast as 64M. Query changes, background processing, and a persistent object cache reduce actual consumption instead of widening the ceiling.

Hostney puts it well in their 2026 requirements guide: if the fix works at 512M and fails again at 2G, the problem is not memory.

Query-Level Fixes

Replace postsperpage => -1 with a real number. Then stop pulling full post objects when you only need IDs:

` $q = new WPQuery( array( 'postsperpage' => 200, 'fields' => 'ids', 'nofoundrows' => true, ) ); `

‘fields’ => ‘ids’ alone cuts allocation dramatically, since WordPress skips hydrating every post object. Understanding how the WordPress query loop actually retrieves and builds posts makes it obvious why the difference is so large.

Then fix autoload. Flip oversized rows to autoload = no and clear expired transients, orphaned postmeta, and post revisions.

Background Processing and Offloading

Action Scheduler exists for exactly this. It claims 25 actions per batch, stops at 90% of available memory or 30 seconds, then fires a loopback request to continue in a fresh PHP process.

Production numbers back it up: queues over 50,000 pending actions, sustained at more than 10,000 actions per hour across 5 concurrent batches (Action Scheduler documentation).

Three offloading moves that pay off:

• Real cron: set DISABLEWPCRON to true, then schedule wp-cron.php every 5 minutes from cPanel or crontab

• Redis or Memcached: a persistent object cache cuts database queries 40-70% per page load (HostAccent, 2026)
• External image processing: hand resizing to a CDN so PHP never decompresses the bitmap

Kinsta runs a server cron every 15 minutes on all hosted sites and recommends disabling WP-Cron outright, which tells you how they weigh the tradeoff.

Which Errors Look Like Memory Exhaustion But Are Not

Four failures produce the same white screen without touching memorylimit: execution timeouts, upload size caps, host-level resource throttling, and PHP parse errors. Each has a distinct log signature, and raising memory on any of them accomplishes nothing.

Timeouts: import and backup plugins running through the admin UI are the most common trigger, and the fix is a longer execution window, not more RAM. A request that simply runs out of time writes “Maximum execution time of 30 seconds exceeded” to the log, never “Allowed memory size.”

Uploads: setting uploadmaxfilesize higher than postmaxsize makes PHP discard the POST body without a word. Nginx adds its own gate through clientmaxbodysize, which returns a 413 response before the request ever reaches PHP.

508 and 503: CloudLinux LVE throttles the whole account when CPU, entry processes, I/O, or account memory peg. LiteSpeed queues and returns a 503 instead of a 508, which is why the two errors point at the same ceiling from different servers.

Database imports: a large SQL file exceeding maxallowedpacket throws a database-level failure mid-import. AHosting’s 2026 guide draws the clean line: a memory failure crashes one page, an EP ceiling event queues or rejects requests sitewide.

And the plain white screen with no logged fatal at all is usually a syntax mistake PHP could not compile. Same for a call to a function that does not exist, which halts execution identically but names a missing function instead of a byte count.

How to Prevent Out of Memory Errors on Production Sites

Set memorylimit to 256M with WPMAXMEMORYLIMIT at 512M, run PHP 8.3, keep autoloaded options under 800KB, and match worker count to available RAM. Audit plugins quarterly and test updates on staging before they reach production.

PHP version does real work here.

PHP 8.3 delivers roughly 14-20% more requests per second than PHP 7.4 on WordPress workloads, and about 23% higher throughput on WooCommerce product pages (HostAccent, 2026).

PHP 7.4 has been end-of-life since November 2022 and still runs 19.288% of WordPress sites as of 2026, per the WordPress.org Statistics API. That is a security problem wearing a performance problem’s clothes.

The worker math nobody does until it breaks:

Available RAM minus what the OS and MySQL need, divided by average process size, gives you pm.maxchildren. DoHost’s 2026 worked example: 6000MB available divided by 100MB average equals 60 workers, or 23 workers if you size against the full 256M ceiling.

Set both numbers together. Raising memorylimit without lowering maxchildren just moves the crash from PHP to the kernel OOM killer.

Housekeeping that actually prevents recurrence:

• Audit plugins quarterly and delete deactivated ones, since inactive themes and plugins left in place keep their database rows
• Test every plugin update on staging first, using Troubleshooting Mode before it reaches live
• Watch peak memory as a metric through Sentry, New Relic, or host-level alerts
• Re-run the autoload query after any plugin removal

Deleting a plugin through wp-admin removes the files and leaves the options behind. WP Multitool found an average autoload payload of 4.2MB across 50+ audited sites, most of it belonging to plugins nobody had used in years.

Clean that up and the allowed memory size exhausted crash usually stops coming back on its own.

FAQ on WordPress Fatal Error: Out Of Memory

What does “Allowed memory size of 268435456 bytes exhausted” mean?

268435456 bytes equals 256M. PHP hit that ceiling on a single request and killed the process. The “tried to allocate” figure shows the last request that broke it, not the total consumption.

How do I increase the WordPress memory limit?

Add define( ‘WPMEMORYLIMIT’, ‘256M’ ); above the "stop editing" line in wp-config.php. If the value does not change, raise memorylimit in php.ini or through your host’s control panel instead.

Why did my wp-config.php edit change nothing?

WordPress cannot exceed the server ceiling. The php.ini value and the PHP-FPM pool config both sit above wp-config.php, so a 256M declaration on a 128M server still gives you 128M.

How much PHP memory does WordPress need?

WordPress.org recommends 256MB for real production sites, though 64MB is the technical floor. Elementor asks for 512MB. WooCommerce stores, membership sites, and LMS installs land in the same 512MB range.

How do I check my current PHP memory limit?

Open Tools, then Site Health, then Info, then the Server panel. That reports what PHP actually enforces. From SSH, wp eval ‘echo iniget(“memorylimit”);’ returns the same value in one line.

Can I get into wp-admin while the site is crashing?

Yes. Recovery mode emails a one-time login link to the administration address and pauses the broken extension. If the email never lands, rename /wp-content/plugins over SFTP to load wp-admin plugin-free.

How do I find which plugin is eating the memory?

Read the folder name in the stack trace first. Then confirm with Query Monitor’s peak memory panel, or isolate plugins through Health Check & Troubleshooting without taking the live site down.

Is setting the limit to 512M or 1024M safe?

Only if worker count matches. Twenty PHP-FPM workers at 256M each is a theoretical 5GB, which does not fit a 4GB VPS. Raise pm.maxchildren and memorylimit together, never separately.

Why does the error only appear during imports or image uploads?

Bulk operations process many objects in one request. GD decompresses each image to a raw bitmap (width x height x 3 bytes), so a 4000px photo consumes roughly 57MB before any resizing happens.

Is this the same as other WordPress fatal errors?

No. Memory exhaustion names a byte count. A cannot redeclare failure names a duplicated function instead, and a 30-second timeout writes “Maximum execution time exceeded.” Different logs, different fixes.

Conclusion

The WordPress fatal error out of memory is almost never a mystery once you read the stack trace instead of guessing at numbers.

Check Site Health first. Confirm what PHP actually enforces before touching a single config file.

Then work down the list:

• Trim autoloaded options back under 800KB
• Move bulk jobs to Action Scheduler or a real system cron
• Add a persistent object cache through Redis
• Run PHP 8.3 and size pm.maxchildren against your actual RAM

A ceiling raised to 512M buys time. It does not fix a plugin looping through 40,000 post objects.

Measure peak usage monthly. The sites that never crash are the ones where somebody watches that number.