How to Increase the PHP Memory Limit in WordPress (WP_MEMORY_LIMIT)

One of the most common WordPress error messages reads something like "Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /wp-includes/...". It usually shows up at the worst possible moment: in the middle of a plugin update, while saving a long page in the editor, during media uploads, or right after switching to a more demanding theme. The fix is almost always raising the PHP memory limit. The catch is that there is not just one memory limit. WordPress has at least three different ones, plus a fourth at the PHP level, and they interact in ways that surprise people. This guide walks through which one applies in which situation and how to raise it on the various host setups.

Which "memory limit" are we even talking about?

When a WordPress page is requested, four limits potentially come into play:

• PHP memory_limit in php.ini. The hard ceiling enforced by PHP itself. Nothing inside WordPress can ever go beyond this. Typical defaults on modern hosts are 128M or 256M.
• WP_MEMORY_LIMIT. WordPress's own constant, defined in wp-config.php. Default is 40M. WordPress raises the PHP limit to this value at boot, but only if WP_MEMORY_LIMIT is higher than the current PHP limit. If your PHP memory_limit is already 256M, this constant has no effect.
• WP_MAX_MEMORY_LIMIT. A separate constant that only applies inside wp-admin (the dashboard, edit screens, plugin and theme management, media library). Default is 256M. Set this higher when admin pages run out of memory but the frontend is fine.
• Hoster overrides. Many shared and managed hosts hard cap PHP memory_limit at the server level, regardless of what your php.ini or wp-config.php says. On those hosts, raising the limit yourself silently fails and you have to ask support.

The practical mental model: WP_MEMORY_LIMIT is for the frontend, WP_MAX_MEMORY_LIMIT is for the admin, and both are floors, not ceilings. They can only raise the effective limit, never lower it below the PHP setting. The PHP setting is the actual ceiling.

How much memory does a WordPress site actually need?

A useful rough scale, based on what InspectWP sees across thousands of scans:

• 64M. A clean WordPress install with a small theme and five well behaved plugins. Realistic only on very simple sites today, and even then tight.
• 128M. The de facto minimum for any real site in 2026. Default theme, ten or fifteen plugins, no page builder. Most hosts default to this.
• 256M. The sensible target for most sites. Page builders (Elementor, Divi, Bricks, Beaver Builder), WooCommerce, larger theme frameworks, image optimization plugins. This is also the default value of WP_MAX_MEMORY_LIMIT for the admin, which is not a coincidence.
• 512M. WooCommerce stores with a few hundred orders and many extensions. Sites running heavy SEO suites alongside a page builder. Image processing on large media libraries.
• 768M to 1024M. Larger WooCommerce shops, multilingual sites with WPML or Polylang, membership sites with complex role logic, sites that run scheduled imports.
• Above 1024M. If you genuinely need this on a normal site, something is usually wrong. A specific plugin is leaking memory, an import job is loading the entire database into a single PHP process, or a theme is doing something it should not. Raising the limit will work around the symptom for now, but the actual fix is somewhere else.

Memory is cheap, but unbounded memory hides bugs. The right move is to raise the limit just enough to make the site work comfortably, not to set it to 4G "just in case".

Option 1: Raise WP_MEMORY_LIMIT in wp-config.php

This is the simplest and most portable change. Open wp-config.php in the WordPress root directory and add the following lines, anywhere above the comment that reads /* That's all, stop editing! Happy publishing. */:

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

Save the file. WordPress applies the new limits on the next request. The frontend now has up to 256M available, the admin up to 512M. No restart is needed.

Important caveat: this only works if the PHP level memory_limit is at least as high as the value you set. If PHP is capped at 128M by the host, defining WP_MEMORY_LIMIT as 512M does nothing. WordPress tries to raise the limit and PHP refuses. The error message stays the same. Continue with Option 2.

Option 2: Raise the PHP memory_limit at the PHP level

If WP_MEMORY_LIMIT alone is not enough, the actual PHP setting needs to come up. Where you change it depends on the host:

On managed hosting (Raidboxes, Kinsta, WP Engine, Cloudways, SiteGround, Pressable)

These hosts almost all expose a setting in their dashboard. Look for "PHP settings", "PHP memory limit" or similar. The change usually takes effect within seconds, no restart needed on your end. Some hosts (Raidboxes, WP Engine) cap the maximum at 512M or 768M for performance reasons. If you genuinely need more, support can usually raise it on request, but they will ask why first, which is the right reaction.

On shared hosting with cPanel/Plesk (IONOS, All Inkl, Hostinger, DomainFactory, Strato)

cPanel and Plesk both have a PHP settings panel where memory_limit can be set per domain. Look for "MultiPHP INI Editor" (cPanel) or "PHP Settings" (Plesk). Pick the value, save, done. Some hosts hide the setting behind a "PHP options" submenu.

If the panel is missing or the setting has no effect, drop a .user.ini file into the WordPress root directory with this single line:

memory_limit = 256M

The .user.ini mechanism is supported by every modern PHP setup running CGI, FastCGI or PHP FPM, which is essentially every host today. PHP picks up the file automatically; the only quirk is a default cache time of five minutes before changes take effect, after which the new limit applies on the next request.

On a self managed VPS or dedicated server

Edit php.ini directly. Find the active php.ini with php --ini on the command line; the path varies by distribution and PHP version. Look for the memory_limit line, change the value, save. Reload PHP FPM with sudo systemctl reload php8.2-fpm (adjust the version number) or restart Apache if you run mod_php.

Apache only: .htaccess (legacy)

On older Apache setups with mod_php (rare on modern hosting), php_value memory_limit 256M in .htaccess can work. If your host runs PHP via FastCGI or PHP FPM, this directive is simply ignored. Use .user.ini instead.

How to verify which limit is actually active

Knowing which of the four limits applies takes thirty seconds:

1. In the WordPress admin, open Tools, Site Health, Info (German: Werkzeuge, Website Zustand, Bericht).
2. Expand the Server section. You see the active PHP memory_limit.
3. Expand the WordPress Constants section. You see WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT, with their current values.

If the WordPress constants show your new values but the PHP memory_limit is still lower, the host caps it at the server level. Talk to support or use the hoster panel from Option 2.

For a precise check from outside the dashboard, drop this temporary file at wp-content/mu-plugins/check-memory.php:

<?php
add_action('init', function () {
    if (current_user_can('manage_options') && isset($_GET['check_memory'])) {
        wp_die('PHP memory_limit: ' . ini_get('memory_limit'));
    }
});

Then open https://yourdomain.com/?check_memory=1 while logged in as admin. The page shows the limit PHP actually applies for that request. Delete the file when you are done.

What if raising the limit does not fix the error?

If "Allowed memory size exhausted" persists after raising every limit to a sane value, the issue is no longer "WordPress needs more memory". Look for one of these:

• A specific plugin is the culprit. Disable plugins one by one and reload. The error pinpoints the plugin in the file path: /wp-content/plugins/PLUGINNAME/.... That plugin either has a memory leak or is genuinely doing something memory intensive that should be split into smaller jobs.
• Bulk operations. Importing thousands of products via WooCommerce's CSV importer, regenerating thumbnails for an entire media library, or running a full SEO audit can all hit any memory limit. The right answer is usually to switch to WP CLI for these tasks. The CLI has a separate, typically much higher memory limit and processes tasks in batches without WordPress's full request lifecycle overhead.
• WP Cron stuck on a heavy task. Background jobs that run via wp-cron.php share the same memory limit as a normal request. If a scheduled task tries to process a huge queue in one go, it fails repeatedly without any obvious frontend symptom. Disabling internal WP Cron and running it via system cron usually helps.
• Object cache misconfiguration. An undersized Redis or Memcached instance combined with WordPress's persistent object cache can cause weird memory pressure under load. Worth checking if you are running one of these and the issue only shows up under traffic.

Common mistakes to avoid

• Setting WP_MEMORY_LIMIT lower than the PHP default. Useless. WordPress only raises the limit, never lowers it. define('WP_MEMORY_LIMIT', '32M') on a host with PHP at 256M does nothing.
• Setting both WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT to the same value. Works, but you give up the ability to let the admin have more memory than the frontend, which is the whole point of having two constants.
• Quoting the value as a number. define('WP_MEMORY_LIMIT', 256) sets the limit to 256 bytes, not 256 megabytes. Always quote with the unit: '256M'.
• Editing the wrong wp-config.php. If your install is in a subdirectory, both the install directory and the parent can have a wp-config.php. Check from the WordPress directory upward and edit the one WordPress actually loads.

For the vast majority of sites, two lines in wp-config.php plus a sensible PHP memory_limit from the hoster panel resolves the error permanently. If it does not, the problem is not memory itself, and raising the limit higher will only delay the next failure.