How to Increase the PHP Memory Limit in WordPress

WordPress core actually tries to fix this problem for you before you ever touch a config file. On every page load, a function called wp_raise_memory_limit() attempts to raise PHP’s memory ceiling to 40MB on the front end (64MB on multisite) and separately to 256MB inside the admin dashboard — but only if your host’s own php.ini hasn’t already set something higher, and only up to whatever hard cap your server allows. That’s why the same site can run fine browsing the front end and then throw a fatal error the moment you try to activate a plugin in wp-admin: the two areas are working against two different ceilings by default, and neither is under your direct control until you override it.

There are three places you can override this: wp-config.php, a php.ini file, or your hosting dashboard. This guide covers all three, plus what WordPress is actually doing internally, so a fix that doesn’t work the first time makes sense rather than feeling random.

Quick Answer

Open wp-config.php and add this line just before the comment reading “That’s all, stop editing! Happy publishing”:

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

Save and reload. If the error clears, you’re done. If it doesn’t, your host is likely enforcing a server-level cap that overrides WordPress’s own constant — move to the php.ini or hosting-panel method below.

Why the PHP Memory Limit Matters

PHP memory exhaustion is one of the most common causes of WordPress errors on shared hosting, showing up as a blank white screen of death, a failed post save, a stalled admin area, or a plugin that refuses to activate. The usual triggers:

• Installing a plugin that needs more memory than your current limit allows
• Running a page builder like Elementor or Bricks on a complex page
• Importing content or running a bulk update
• WooCommerce processing a large product catalogue
• A caching plugin regenerating cache files across the whole site at once

Given that WordPress core’s own front-end default is only 40MB — well below what a modern plugin stack typically needs — hitting this ceiling on a page builder or WooCommerce site isn’t a sign of anything unusual, it’s the expected outcome of core’s conservative default meeting real-world plugin weight. 256MB is a safe general baseline for most small to medium sites; larger WooCommerce stores or heavy image-processing workloads may need more.

Step 1 — Check What WordPress Is Actually Using

Go to Tools → Site Health → Info and scroll to the PHP section. You’ll see two separate numbers: the memory limit your server’s php.ini allows, and the WP_MEMORY_LIMIT value WordPress itself is working with — these can differ, since WordPress’s constant can only raise the limit up to whatever the server permits, never past it. The Site Health tool also flags memory as a concern automatically if the value looks too low. If it already reads 256MB or higher, memory isn’t your problem — look elsewhere.

Step 2 — Edit wp-config.php (Try This First)

Open your file manager in cPanel or connect via FTP, navigate to your WordPress root, and open wp-config.php. Find:

/* That's all, stop editing! Happy publishing. */

and add immediately above it:

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

Save, then re-check Tools → Site Health → Info to confirm the new value took. Full documentation for this constant lives in the WordPress developer docs on wp-config.php.

If admin-heavy tasks — bulk plugin updates, large media uploads — still hit the ceiling, add a second constant for the admin-specific limit WordPress applies inside wp-admin:

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

Step 3 — Edit php.ini (If wp-config.php Has No Effect)

If wp-config.php makes no difference, your host is setting the limit at the server level in a way that overrides WordPress’s own constant entirely — this is common on budget shared hosting, where PHP resources are pooled tightly across many accounts. Look for (or create) a php.ini file in your site’s root and add:

memory_limit = 256M

Some Apache-based hosts also accept the equivalent directive in .htaccess:

php_value memory_limit 256M

Whether either method works depends entirely on how your host has configured PHP — some lock this down completely to prevent one account from monopolising shared resources.

Step 4 — Use Your Hosting Control Panel

Many cPanel-based and managed hosts expose a PHP settings screen that changes the limit without touching a file at all:

• cPanel: under Software, look for Select PHP Version or PHP Configuration, then find and update memory_limit.
• SiteGround / Cloudways and similar managed hosts: a PHP Settings or Server Settings section, usually set to 256M directly.
• Local (by WP Engine): right-click the site, go to Site setup → PHP version, and adjust from there.

If none of these appear, contact your host’s support and ask them to raise the memory limit to 256MB directly — most reputable hosts do this without pushback.

Reading the Actual Fatal Error Message

A memory-exhaustion error has a specific, recognisable shape that’s worth knowing before you start changing settings blind. It reads something close to:

Fatal error: Allowed memory size of 41943040 bytes exhausted (tried to allocate 20480 bytes) in /home/site/wp-includes/... on line ...

Two numbers matter here. The first — 41,943,040 bytes — is your current ceiling in raw bytes; divide by 1,048,576 and it converts back to a familiar 40MB, which is exactly WordPress core’s own front-end default mentioned above, not a host-specific number. That’s a useful diagnostic in itself: if the exhausted figure in the error converts cleanly to 40MB or 64MB, you’re looking at WordPress’s own unconfigured default, not a custom host limit, which tells you a wp-config.php edit is very likely to fix it outright. The second number — the “tried to allocate” figure — is usually small, because the fatal error typically fires on the single allocation that finally tips the process over the edge, not on one giant request; the real cause is everything that accumulated in memory before that point (a large product import, a page builder rendering a complex layout, a plugin holding data in memory across a long-running process). This is also why doubling the limit sometimes still isn’t enough for a genuinely heavy WooCommerce import — the process was already close to whatever ceiling you set, and it just needed slightly more headroom than a round number happened to provide.

Practical Tips

256MB is the safe default I start with on most sites I build — it comfortably covers a standard shared-hosting stack. Jumping straight to 512MB or 1GB rarely improves anything; it just reserves memory PHP was never going to need, without making pages load faster.

Always confirm the change in Site Health, not just by checking whether the white screen disappeared — the Info tab shows exactly what value WordPress is reading, which confirms the fix landed at the right layer rather than being silently overridden by the server.

If the error persists after raising the limit, the cause may not be memory at all — deactivate plugins one at a time to isolate a conflict. A single poorly coded plugin can exhaust even a generous allocation on its own.

Common Mistakes

• Adding the line in the wrong place. It must sit before the “stop editing” comment — lines added after it aren’t reliably processed.
• Wrong value format. Write '256M', not 256 or '256MB' — PHP expects the bare M suffix.
• Assuming wp-config.php always wins. On restrictive shared hosts, the server-level limit overrides WordPress’s constant entirely. If Site Health doesn’t reflect the change, move to php.ini or your host.
• Setting it too low the first time. Going from 64MB to 128MB when 256MB was actually needed just means repeating this process in a few months.

When to Contact Your Host Instead of Editing Further

If all three methods leave Site Health showing the original value, your host is enforcing a hard cap at the server level — typical on budget shared hosting where resources are pooled across many accounts. From there: ask support to raise the limit for your account specifically, upgrade to a higher hosting tier, or move to a host with more flexible PHP configuration. Sites that have genuinely outgrown budget shared hosting usually find that a VPS or managed WordPress plan resolves memory and performance issues together, since the two are often symptoms of the same underlying resource ceiling.

Conclusion

Start with wp-config.php — it works on most hosts and takes under two minutes. If it has no effect, work through php.ini and your hosting control panel before contacting support. Once Site Health confirms the new limit, most memory-related WordPress errors clear immediately. For the broader process from choosing a host to a fully working site, see the step-by-step guide to building a WordPress website.