Set both limits with intent: use PHP memory_limit as the real ceiling, then use WP_MEMORY_LIMIT to tell WordPress how much of that ceiling it may request. WordPress commonly defines WP_MEMORY_LIMIT at 40 MB for single-site installs and 64 MB for multisite, while admin tasks may use WP_MAX_MEMORY_LIMIT, often 256 MB [source: WordPress Developer Resources]. If your site is slow, throwing fatal errors, or breaking during plugin updates, start by checking the PHP limit first. Then tune WordPress.
TLDR: PHP memory_limit controls how much memory a PHP process can use, while WP_MEMORY_LIMIT is WordPress asking for a certain amount inside that PHP process. For example, if PHP is capped at 128 MB and WordPress asks for 256 MB, your host may still stop the process at 128 MB. A WooCommerce store with 42 active plugins may run fine at 256 MB but hit fatal errors at 128 MB during imports. Set PHP to 256 MB or 512 MB first, then set WordPress to match the real workload.
Why WordPress memory settings are confusing
WordPress memory errors look simple, but they rarely are. You see a message like “Allowed memory size exhausted”, raise one value, refresh the page, and nothing changes. It drives me crazy that many hosting panels show one memory number while WordPress reports another.
The confusion comes from two layers:
PHP memory_limit: The PHP runtime limit. It applies to each PHP process.WP_MEMORY_LIMIT: A WordPress constant that requests memory for normal front-end and back-end operations.WP_MAX_MEMORY_LIMIT: A higher WordPress limit used for heavier admin actions, such as image editing, updates, and some imports.
Think of PHP as the building owner and WordPress as a tenant. WordPress can ask for a bigger room, but PHP and the host decide if that room exists.
What PHP memory_limit actually does
memory_limit is a PHP configuration directive. It limits the memory a single PHP script may consume. It is not the total RAM on your server. If your server has 8 GB of RAM, that does not mean one WordPress request can use 8 GB.
You may find this setting in several places:
php.ini.user.ini.htaccess, on some Apache setups- cPanel, Plesk, or another hosting panel
- Managed hosting settings
- Container or server configuration
A common value is 128 MB. Small brochure sites can survive with that. Larger WordPress sites often need 256 MB. Busy WooCommerce stores, membership platforms, and sites with page builders may need 512 MB for stable admin work.
PHP describes memory_limit as the maximum amount of memory a script may consume [source: PHP Manual]. That single sentence explains many WordPress headaches.
What WP_MEMORY_LIMIT actually does
WP_MEMORY_LIMIT is usually added to wp-config.php. It looks like this:
define( 'WP_MEMORY_LIMIT', '256M' );This tells WordPress to request up to 256 MB. It does not always guarantee that WordPress gets 256 MB. If your host blocks runtime memory changes, the setting may be ignored. If ini_set() is disabled, WordPress cannot raise the value by itself.
Expect to waste time if you only edit wp-config.php and skip the server setting. You may reload the Site Health screen and still see the old number. That usually means PHP or the host has the final say.
What about WP_MAX_MEMORY_LIMIT?
WP_MAX_MEMORY_LIMIT is used for heavier tasks in the admin area. You can define it like this:
define( 'WP_MAX_MEMORY_LIMIT', '512M' );This is useful when the public site works fine, but the admin area breaks during media uploads, bulk plugin updates, backups, or imports.
For example, a recipe site with 18,000 images may load the front end at 128 MB. But regenerating thumbnails can fail unless admin memory is raised to 512 MB. That does not mean every visitor uses 512 MB. It means larger admin jobs have more breathing room.
Image not found in postmeta
Which one should you change first?
Change PHP memory_limit first. Then set the WordPress constants.
Use this order:
- Check the current PHP limit. Use WordPress Site Health, a hosting panel, or a small PHP info page.
- Raise PHP memory if needed. For many serious WordPress sites, 256 MB is a sane starting point.
- Add
WP_MEMORY_LIMIT. Match it to the front-end workload. - Add
WP_MAX_MEMORY_LIMIT. Use a higher value for admin tasks if needed. - Retest the failing action. Do not guess. Retry the import, update, checkout, or image job that failed.
A solid general setup looks like this:
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );If PHP itself is still set to 128 MB, these lines may not help. Fix the server limit too.
How to know you have a real memory problem
Memory issues are often loud. They break pages. They kill imports. They produce fatal errors. Still, not every slow page is a memory problem.
Watch for these signs:
- Fatal error: “Allowed memory size exhausted.”
- White screen: Often caused by a plugin failing mid-request.
- Failed imports: Especially product, user, or media imports.
- Update failures: Plugin or theme updates stop halfway.
- Image issues: Large uploads fail or thumbnail creation stalls.
If the admin dashboard takes 9 seconds longer after installing a reporting plugin, memory may be part of the problem. But CPU, database queries, object cache, and bad plugin code can also be involved.
Common mistakes
The first mistake is setting memory absurdly high. A limit like 2048 MB may hide bad code instead of fixing it. It can also allow one bad request to consume too many resources.
The second mistake is thinking memory is shared evenly. A 512 MB limit means one PHP process may use up to 512 MB. Ten heavy requests can create serious pressure on smaller servers.
The third mistake is ignoring plugins. A single bloated plugin can add more memory use than an entire lightweight theme. Backup plugins, security scanners, page builders, analytics dashboards, and import tools are common suspects.
Image not found in postmeta
Practical recommendations
For a small content site, use 128 MB to 256 MB. For a business site with forms, SEO tools, and page builder features, use 256 MB. For WooCommerce, LMS, membership, or multilingual sites, start with 512 MB for admin tasks.
Keep the front end lean. The public side should not need huge memory unless plugins are doing too much on every request. Cache pages where possible. Audit plugins twice a year. Remove inactive themes and old tools.
Use this simple rule: raise memory to support valid work, not to excuse wasteful code. If a checkout page needs 512 MB just to load, something is wrong.
The best setup for most WordPress sites
The cleanest setup is a PHP limit that matches your hosting plan, plus WordPress constants that reflect real use. For many sites, that means PHP memory_limit at 256 MB or 512 MB, WP_MEMORY_LIMIT at 256 MB, and WP_MAX_MEMORY_LIMIT at 512 MB.
Do not treat these values as magic. Treat them as guardrails. If raising memory fixes the crash, great. If the site still feels sluggish, check queries, plugins, cron jobs, and hosting resources next. Memory is only one part of WordPress performance, but when it is too low, everything else feels broken.