WordPress "Allowed Memory Size Exhausted" Fatal Error Fix

You update a plugin, import a batch of products, or just load a heavy page, and WordPress throws back: "Fatal error: Allowed memory size of X bytes exhausted (tried to allocate Y bytes)". The screen goes white or half-renders, and now you're stuck between raising a number and actually fixing the problem. Here's how to do both.

What This Error Actually Means

PHP caps how much RAM a single script can use at once — that's the memory_limit setting. It has nothing to do with your server's total RAM. A VPS with 8GB free can still throw this error if PHP itself is only allowed 128MB for that one request. WordPress just happened to need more than that ceiling to finish the job it was doing.

This is different from a server running out of physical memory and the kernel's OOM killer terminating processes — that's a host-level crash, not a per-script cap, and it looks completely different in your logs (no PHP fatal error, just a killed process). If you're chasing that instead, it's a separate problem with its own fix.

Symptom: What You'll See

• A white screen or a broken layout with the fatal error text printed on it
• The error naming a specific file, often deep in wp-includes, a plugin folder, or an image-processing library
• It happens only on specific actions — bulk imports, PDF generation, image resizing, or a specific plugin's admin page — not the whole site
• In wp-content/debug.log or your PHP error log, the same message with a byte count

Common Causes

1. The PHP memory_limit is genuinely too low

Shared hosting defaults are often 128MB or 256MB. That's plenty for a lean blog, tight for WooCommerce, and not enough for a plugin doing bulk operations, PDF invoices, or large image manipulation in one request.

2. A plugin or theme is leaking memory

Sometimes the limit isn't the problem — a plugin is. A loop that never releases objects, a page builder rendering huge nested shortcodes, or an image library processing an oversized photo can eat memory far faster than normal. Raising the limit just delays the crash; it doesn't fix the leak.

3. WP_MEMORY_LIMIT is set, but the host's hard cap overrides it

WordPress lets you set WP_MEMORY_LIMIT in wp-config.php, but that value can never exceed what your hosting account's PHP configuration actually allows. If your host caps PHP at 256MB account-wide, telling WordPress to use 512MB does nothing — PHP still stops at 256MB.

4. A one-off heavy job — import, migration, backup

Restoring a big database, running an All-in-One Migration import, or a backup plugin zipping a large uploads folder are classic one-time spikes. These often need a temporarily higher limit rather than a permanent one.

The Fix

Step 1 — check your current limit

Add this temporarily to a plugin like Query Monitor, or check via WP-CLI if you have SSH access:

wp eval 'echo ini_get("memory_limit");'

Or from cPanel: Software → MultiPHP INI Editor, select your domain, and look at the memory_limit value under the Editor tab.

Step 2 — raise it in wp-config.php

Open wp-config.php and add this near the top, before the line that says /* That's all, stop editing! */:

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

WP_MEMORY_LIMIT covers regular front-end and admin pages. WP_MAX_MEMORY_LIMIT applies to memory-heavy admin tasks like the Media Library and plugin updates. Set both.

Step 3 — raise the actual PHP limit, not just WordPress's request

If your host allows it, this is where the real ceiling lives. In cPanel, go to MultiPHP INI Editor and bump memory_limit directly:

memory_limit = 512M

No MultiPHP INI Editor? Try a php.ini in your account root, or add this to .htaccess on Apache setups (this won't work on Nginx or PHP-FPM pools with restricted overrides):

php_value memory_limit 512M

Step 4 — if nothing moves the needle, it's a hard cap

Some shared plans lock PHP memory account-wide regardless of what you set in .htaccess or wp-config.php. If the error persists after Steps 2–3, that's your signal — you'll need your host to raise the account cap, or move to a plan/VPS where you control PHP-FPM pool settings directly.

Find the Actual Memory Hog — Don't Just Keep Raising the Number

If you're already at 512M and still hitting the wall, something is misbehaving. Raising the limit again just buys time before a bigger version of the same crash.

1. Install Query Monitor and check the memory tab after reproducing the error — it'll show peak usage and often points at the plugin responsible.
2. Disable plugins one by one (or deactivate all, then reactivate in batches) and repeat the action that triggers the fatal error.
3. Check if the trigger is a specific file type — huge uncompressed photos from a phone camera routinely blow past memory limits during thumbnail generation.
4. For bulk imports, look for a "batch size" or "items per run" setting in the importer plugin and lower it instead of raising server memory indefinitely.

Prevention

• Set WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT in wp-config.php as a baseline on every new WordPress install
• Keep image uploads reasonably sized — a plugin like Imsanity or Smush's resize-on-upload feature prevents the giant-photo problem before it starts
• Run large imports and migrations during low-traffic hours, in smaller batches, not one giant file
• Audit plugins after any fatal error — a memory leak rarely fixes itself, and it usually gets worse with the next update
• If you're on shared hosting and keep hitting the account-wide cap, that's usually a sign it's time for a VPS where you control the PHP-FPM pool's memory_limit directly

Quick Reference

If you're on Getwebup hosting and can't push memory_limit past your current plan's ceiling through MultiPHP INI Editor, open a ticket — we can tell you exactly where the cap sits and whether your plan supports a higher one, or help you move to a VPS with full PHP-FPM control.