How to raise the WordPress memory limit

Symptoms

A page, the dashboard, or a background job dies with a PHP fatal error that reads, for example, Allowed memory size of 67108864 bytes exhausted (tried to allocate 262144 bytes). The number varies, but the pattern is fixed: PHP hit the cap a single request is allowed to use and abandoned the render. On some hosts the fatal is suppressed and the same failure shows as a blank page or a 500, which is why this and the white screen of death go together.

Why memory limits matter

Every PHP worker gets a ceiling set by the PHP runtime. WordPress itself can run in under 64 MB for a simple site, but themes and plugins (page builders, WooCommerce, search plugins, image libraries) routinely raise demand. The limit is a safety valve: the correct fix is not a permissive cap, it is a cap high enough for your real workload with a check that tells you what is actually hungry.

The fix order

1. Raise the cap in the right file. WordPress reads WP_MEMORY_LIMIT from wp-config.php (real memory) and WP_MAX_MEMORY_LIMIT for admin screens (the dashboard edits, media imports, and block rendering areas):

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

With normal layouts, the define can be added above the "stop editing" line. Confirm WordPress took the value via the admin area: Tools, Site Health, or the memory_limit column on the Info screen shows the PHP value. If the constant is set but the value stays low, the host caps it, covered next.

1. Confirm the underlying PHP limit. WordPress wins over a base value, but the server's php.ini set memory_limit can still stop a request before WordPress runs, and CLI events use their own ini. Check with:

php -r "echo ini_get('memory_limit');"

If the host denies raising php.ini, or you have no CLI access, add the fallback inside .htaccess for Apache (rarely honored by modern hosts) or ask the host for the per-account PHP memory setting in the panel.

1. Find the leak, do not just raise. A cap bump usually quiets the symptom, but the honest next step is to prove which code grows without bound. Turn on the error log and look at the largest memory consumers:

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

Restart and inspect wp-content/debug.log. If one plugin's hook swells to 300 MB every render, raise the cap to the real need but also consider that plugin in staging.

1. Check the classic culprits in order. In plugins whose every asset gets loaded on every page, a page builder that hydrates the full block set, a gallery plugin that loads full-size images into PHP, an import or cron job that processes whole tables in one pass. Move those to background jobs or batch processing.
2. Verify after the change. Reload the failing page and read the same log. If a Fatal error line with Allowed memory size remains, the request needs either a larger cap or a search for the actual tight loop, often a loop appending to a string inside a theme's filter.

Prevention

• Raise the limit once for a reason, and record the value in your deploy config so a fresh install does not regress it.
• Keep WP_DEBUG_LOG at true in production but WP_DEBUG_DISPLAY false, and rotate the log, so the next memory error prints to a file instead of the visitor's screen.
• Watch cron and background imports in the log; memory limits apply to them too, and they fail far away from the browser.

When to involve a professional

If a plugin request reliably exceeds 512 MB, the limit is not the story. The story is a plugin or theme holding an image or query in memory one object at a time. A developer can trace that with a profiler in a day; raising the cap will only delay the crash.