How to edit the WordPress excerpt length easily
May 24, 2026Finance Website Design Examples to Ignite Your Creativity
May 30, 2026Your WordPress site was working fine, then suddenly it wasn't.
A blank screen, a cryptic fatal error, or a frozen wp-admin panel. Nine times out of ten, that's the PHP memory limit telling you it has run out of room.
Knowing how to fix the WordPress memory limit is one of those skills that saves hours of frustration. The error is common, the causes are specific, and the fixes are direct once you understand which configuration layer is actually in control.
This guide covers everything: reading your current memory values, editing wp-config.php, php.ini, and .htaccess, using your hosting control panel, and stopping the allowed memory size exhausted error from coming back.
What Is the WordPress Memory Limit?
The WordPress memory limit is the maximum amount of RAM a single PHP process is allowed to use when your site handles a request. WordPress powers over 43.5% of all websites on the internet (W3Techs, 2025), and every one of those sites runs inside this memory constraint.
3 separate configuration layers control the actual memory available to your site. Understanding which one is in charge is what separates a real fix from one that does nothing.
| Setting | Where it lives | Who controls it |
|---|---|---|
| memory_limit | Server php.ini | Hosting provider |
| WPMEMORYLIMIT | wp-config.php | Site owner |
| WPMAXMEMORY_LIMIT | wp-config.php | Site owner (admin only) |
The server-level php.ini value is always the hard ceiling. WordPress cannot exceed it, regardless of what you put in wp-config.php.
What Controls the Memory Limit in WordPress
Default values out of the box: WordPress sets WPMEMORYLIMIT to 40MB for single-site installs and 64MB for multisite (Contabo, 2024). Most shared hosts override this with their own server-level php.ini value, usually between 64MB and 256MB.
The 3 settings work in a clear hierarchy:
- memory_limit (php.ini): The absolute cap. Nothing overrides it.
- WPMEMORYLIMIT: Controls front-end and general PHP processes.
- WPMAXMEMORY_LIMIT: Controls the wp-admin area separately. Defaults to 256MB.
If WPMEMORYLIMIT is set to 512M but the server php.ini says 256M, PHP uses 256M. The WordPress value gets silently ignored.
What the "Allowed Memory Size Exhausted" Error Means
When PHP tries to allocate more RAM than the limit allows, it kills the process immediately and throws a fatal error. The exact message looks like this:
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes)
That number, 134217728 bytes, is 128MB. The error shows the current limit in bytes, not megabytes, which confuses a lot of people the first time they see it.
The error can surface in 3 ways: a blank white screen (the white screen of death), a visible error message on the front end, or a silent failure logged to the WordPress debug log when WP_DEBUG is active.
I'm interrupting the article to tell you about BeTheme, the definitive multipurpose theme. If trying to satisfy multiple clients has become more stressful than rewarding, BeTheme is the solution for that.
BeTheme’s selection of hundreds of customizable, responsive pre-built websites is the highlight and a proven stress reducer.
The customizability of the theme makes it a dream come true for its users. There are 4 types of Page Builders that you can use with it: WPBakery, BeBuilder, and Elementor among them.
And now with the Live Builder, it’s even more impressive.
Check out BeTheme and see why our users love it!
The rest of the article is down below.
What Causes the WordPress Memory Limit to Be Exceeded?
The memory exhausted error is almost never caused by a single event. It builds up. A clean WordPress installation uses well under 10MB of PHP memory per request. The problem starts when layers of plugins, themes, and media processing push that number past the server ceiling.
Dev4Press (2024) puts it clearly: with an average of 20 active plugins, a modern WordPress site needs between 48MB and 64MB just for routine page loads. Add a page builder or an e-commerce layer and that number climbs fast.
The 5 most common causes of PHP memory exhaustion:
- Heavy page builders: Elementor officially requires 256MB and recommends 512MB. Running it alongside WooCommerce can push requirements to 768MB (Elementor, 2024).
- WooCommerce stores: Managing products, cart logic, payment gateways, and inventory simultaneously is genuinely memory-intensive.
- Backup and security plugins: Tools like UpdraftPlus, Wordfence, and BackupBuddy load significant code on every request, not just when running a backup or scan.
- Poorly coded plugins: Some plugins do not release memory properly after they finish executing. They allocate RAM and hold it.
- Large media operations: Uploading high-resolution images or running batch imports in wp-admin creates a temporary spike in PHP memory usage that can exceed the limit even if normal page loads are fine.
Shared hosting is where this hits hardest. Hosts on shared plans often set the server php.ini ceiling at 64MB or 128MB to protect shared resources, which leaves almost no room for growth.
How to Check the Current WordPress Memory Limit
Check the actual active values before touching any configuration file. The number you see in wp-config.php may not be what PHP is actually using.
3 ways to read your current memory limit:
- Site Health tool: Go to Tools > Site Health > Info > Server. Shows both the WordPress-reported value and the server-enforced PHP limit side by side.
- Query Monitor plugin: Displays per-request memory usage in real time from the admin bar. Useful for tracking which specific pages or actions are consuming the most RAM.
- phpinfo(): Create a temporary file in your WordPress root containing
<?php phpinfo(); ?>, load it in a browser, and search for "memory_limit". Delete the file immediately after checking.
The Site Health tool is the safest option for most users. It requires no file access and no plugin installation.
Pay attention to the difference between the two values shown. If WordPress reports 256M but PHP shows 128M, the server ceiling is the real limit. Editing wp-config.php alone will not fix the problem in that case.
How to Increase the WordPress Memory Limit in wp-config.php
This is the first fix to try. It works on most shared hosting setups and takes under 2 minutes.
Open wp-config.php via FTP, SFTP, or your host's file manager. Find the line that reads /* That's all, stop editing! */ and add the following directly above it:
define('WP_MEMORY_LIMIT', '256M');Save the file and reload your site. Check Site Health again to confirm the new value is active.
What Value Should You Set
Recommended values depend on what you're running:
| Site type | WPMEMORYLIMIT | Notes |
|---|---|---|
| Basic blog / brochure site | 128M | Covers most lightweight setups |
| Site with Elementor or Divi | 256M | Elementor's stated minimum |
| WooCommerce store | 512M | Elementor + WooCommerce together |
| WordPress Multisite | 64M+ | WordPress default is 64M for multisite |
For wp-admin errors specifically, set WPMAXMEMORY_LIMIT separately. Add this line directly below the first one:
define('WP_MAX_MEMORY_LIMIT', '512M');When wp-config.php Changes Do Nothing
If setting WPMEMORYLIMIT to 256M makes no difference, the server php.ini ceiling is below 256M. WordPress cannot override a server-level limit from wp-config.php. The fix in that case moves to php.ini, .htaccess, or your hosting control panel.
This is the most common point of confusion. The wp-config.php definition raises the WordPress limit, but only up to whatever the server allows. If the host has set a hard cap at 128M, define('WP_MEMORY_LIMIT', '512M') will silently do nothing.
How to Increase the Memory Limit via php.ini
The php.ini file is where the server-level PHP memory limit actually lives. Changing it here overrides what any CMS, including WordPress, can request.
Locate the correct php.ini for your setup. On shared hosting this is usually a per-directory php.ini you create yourself. On a VPS or dedicated server it is typically at /etc/php/[version]/fpm/php.ini or /etc/php.ini.
How to Find and Edit php.ini on Shared Hosting
If direct php.ini access is blocked by the host:
- Create a new file named
php.iniin your WordPress root directory (same folder as wp-config.php) - Add one line:
memory_limit = 256M - Save and upload the file
- Verify with phpinfo() or Site Health that the change is active
Most shared hosts accept a per-directory php.ini. Whether it works depends on the host's configuration. If it does not take effect, the cPanel PHP settings panel is the next step.
Note: a 500 error after creating or editing php.ini usually means the server is running PHP-FPM or Nginx, where per-directory php.ini files are not supported. In that case, skip to the hosting control panel method.
How to Edit php.ini on a VPS or Dedicated Server
On a VPS, you have root access. Find the active php.ini using:
php --iniOpen the file, find the line memory_limit = 128M, and change the value. Restart PHP-FPM after saving:
sudo systemctl restart php8.2-fpmConfirm the change took effect by running php -i | grep memory_limit from the command line.
How to Increase the Memory Limit via .htaccess
The .htaccess method works on Apache servers running mod_php. It does not work on Nginx or on Apache setups using PHP-FPM. If you are not sure which setup your host uses, try wp-config.php or the hosting panel first.
Open your .htaccess file (in the WordPress root directory) and add this line above the WordPress rewrite block:
php_value memory_limit 256MThe WordPress rewrite block starts with # BEGIN WordPress. Place the directive before that line, not inside it.
3 things that can go wrong with this method:
- 500 error immediately: The server runs PHP-FPM or Nginx. Remove the line, revert the file. The directive is incompatible with that server type.
- No change in Site Health: The server is Apache but the host disallows php_value overrides in .htaccess. Move to the cPanel PHP settings panel.
- Change confirmed but error persists: The server ceiling in the global php.ini is still below your new value. Contact the host.
Always keep a backup of .htaccess before editing it. A corrupted .htaccess file takes down the entire site's URL routing, not just memory settings. If you're dealing with other WordPress .htaccess issues, it is worth auditing the full file at the same time.
How to Increase the Memory Limit from the Hosting Control Panel
This is the most reliable method for shared hosting users who cannot edit php.ini directly. The host's control panel modifies the PHP configuration at the server level, which means the change actually sticks.
Where to find the setting depends on your hosting panel:
- cPanel: Software > MultiPHP INI Editor > select the PHP version for your domain > set memory_limit
- Plesk: Domains > your domain > PHP Settings > memory_limit
- SiteGround: Site Tools > Devs > PHP Manager > PHP Variables
- Kinsta (MyKinsta): Site > Tools > PHP memory limit slider (goes up to 768MB on most plans)
After saving the new value, verify it in Site Health. If Site Health still shows the old limit, log out of cPanel or the hosting panel, clear your browser cache, and check again. Some hosts require a few minutes for the change to propagate.
When the Host Sets a Hard Ceiling You Cannot Raise
Shared hosting plans almost always have a maximum memory value the panel lets you set. On many budget hosts that ceiling is 256MB. If your site needs more and you cannot raise it further, there are 2 options: contact hosting support directly and ask them to raise the php.ini ceiling for your account, or upgrade to a VPS plan where you control the server configuration. Kinsta provides 8GB of RAM on standard plans (Kinsta, 2024), which puts server-level memory limits out of reach for most WordPress sites.
Reaching out to hosting support is faster than most people expect. A live chat message asking to raise the PHP memory_limit to 512M usually takes under 10 minutes to resolve on quality managed hosts.
What to Do When the Memory Limit Cannot Be Increased Further
Hitting the server ceiling is a different problem from simply setting the wrong value. When the host's hard cap is already at its maximum and the PHP memory exhaustion error persists, raising the limit is no longer an option. The fix moves to reducing how much memory the site actually consumes.
91% of WordPress vulnerabilities originate from third-party plugins, and the same bloated plugins causing security exposure are usually the ones consuming the most memory (DWS, 2024). Both problems get solved by the same audit.
How to Find Which Plugin Is Using the Most Memory
Query Monitor is the standard tool for this. Install it, load the page where the memory exhausted error fires, and open the Overview tab from the admin bar. It shows peak memory usage for that specific request and maps database queries back to the plugin or theme that triggered them.
Step-by-step isolation process:
- Note the peak memory shown in Query Monitor's Overview tab before any changes
- Deactivate plugins one at a time, reloading the problem page after each deactivation
- Watch the peak memory figure drop in Query Monitor after each deactivation
- The plugin whose removal causes the largest memory drop is the primary consumer
If Query Monitor itself pushes the site over the limit (this can happen on sites with hundreds of database queries per request), use the Plugin Memory Usage plugin instead. It measures the memory delta when each plugin activates, giving you a ranked list of memory impact per plugin without needing to deactivate them manually.
When to Upgrade Your Hosting Plan
Some sites genuinely need more memory than shared hosting allows. A WooCommerce store running Elementor, a membership plugin, and a multilingual setup with WPML can legitimately require 512MB to 1024MB of PHP memory per request (InspectWP, 2026).
Signs the hosting plan is the actual bottleneck:
- The host's control panel ceiling is at 256MB and cannot be raised through support
- You've removed non-essential plugins and the memory error still fires
- The site runs PHP 8.2+ and the error still persists after the PHP version upgrade
Moving to a VPS gives full control over php.ini, which means no ceiling except the physical RAM of the server. Kinsta's managed WordPress hosting provides 8GB of RAM on standard plans (Kinsta, 2024), making PHP memory limit errors essentially impossible for most production sites.
Replacing Elementor with a lighter page builder is worth considering before upgrading. Not every site actually needs a full page builder, and swapping to a block-based theme removes that 256MB minimum requirement entirely.
How to Fix the WordPress Memory Limit Error in wp-admin Only
A memory error that appears only in wp-admin but not on the front end is almost always a WPMAXMEMORYLIMIT issue, not a WPMEMORY_LIMIT issue. These are two separate PHP memory allocations that WordPress controls independently.
WPMAXMEMORY_LIMIT defaults to 256MB (WPZOOM, 2025). Admin tasks routinely need more than front-end page loads because they involve file operations, plugin updates, media processing, and bulk database actions happening in a single PHP process.
What Triggers Admin-Only Memory Errors
\\Admin memory errors\\ cluster around 4 specific actions:
- Bulk plugin or theme updates pulling and unpacking multiple ZIP files simultaneously
- Media library operations, especially regenerating thumbnails for large image libraries
- Content imports using tools like WP All Import or the native WordPress importer
- Running wp-cron tasks manually or triggering scheduled backups from the dashboard
Front-end pages serve cached HTML or run a constrained set of queries. The admin area runs raw PHP processes with no caching layer. That's why the same site can load fine on the front end while the dashboard throws a PHP fatal error.
The Exact Fix for Admin Memory Errors
WP Engine recommends setting WPMAXMEMORY_LIMIT to a maximum of 512MB for administration tasks (WP Engine support documentation).
Add this line to wp-config.php, directly below your WPMEMORYLIMIT definition:
define('WP_MAX_MEMORY_LIMIT', '512M');Save, then rerun the exact action that triggered the original error. If it completes without a fatal error, the fix worked. If the error persists, the server php.ini ceiling is below 512MB and you need to raise it at the hosting control panel level first.
Key distinction: WPMAXMEMORYLIMIT is a floor, not a ceiling. It raises the effective admin limit up to whatever the server allows. It cannot exceed the server's php.ini memorylimit value (InspectWP, 2026).
How to Prevent the WordPress Memory Limit Error from Recurring
Fixing the error once is straightforward. Keeping it from coming back takes a different approach: setting limits above your actual peak usage, reducing what the site loads by default, and monitoring memory consumption over time rather than reacting to it after a crash.
Elementor appears on 31.2% of live WordPress sites (W3Techs, 2026), and sites running it alongside WooCommerce represent the most common category of recurring memory errors. Both tools are legitimately memory-intensive. The fix is not always removing them. It is making sure the server environment is sized for what the site actually runs.
Set Limits Above Peak, Not Just Above the Error Threshold
A common mistake: setting WPMEMORYLIMIT to exactly the value that stopped the last error. That leaves no headroom.
Set your memory limit to 20-30% above your actual peak usage as shown in Query Monitor. If your site peaks at 180MB under normal load, set the limit to 256M, not 192M. Traffic spikes, plugin updates, and background cron jobs all temporarily push memory higher than baseline.
Use Object Caching to Cut Per-Request Memory Load
By default, WordPress rebuilds its object cache on every single PHP request. Redis and Memcached make that cache persistent across requests, which reduces the volume of database queries each PHP process has to run.
What object caching reduces:
- Repeated wp_options queries that reload on every page load
- User metadata lookups on sites with logged-in users
- WooCommerce session data retrieval on cart and checkout pages
Redis works best on dynamic sites: WooCommerce stores, membership platforms, and LMS installations where full page caching does not apply (Pressidium, 2025). A static brochure site with a full page cache enabled gets little benefit from Redis because WordPress never loads in the first place.
Run a Plugin Audit Every Quarter
Deactivated plugins still load their files during PHP initialization on some WordPress configurations. Deleted plugins do not.
Every plugin on a WordPress install contributes to base memory allocation on page load. Dev4Press (2024) shows an average of 20 active plugins pushes baseline memory to 48-64MB before any page-specific logic runs. A site with 40 active plugins can realistically double that baseline.
Check your WordPress plugin setup every quarter. Remove anything unused. Replace memory-heavy plugins with leaner alternatives when the functionality is simple enough not to require a full-featured solution.
Keep PHP Updated for Memory Efficiency
PHP 7.4 still powers 19.288% of WordPress sites as of 2026 (WordPress.org Statistics API). That's a meaningful performance gap sitting on the table for nearly one in five WordPress installs.
| PHP Version | Performance vs 7.4 | Key memory change |
|---|---|---|
| PHP 7.4 | Baseline | No JIT compiler |
| PHP 8.0 | +~1% general | JIT compiler introduced |
| PHP 8.1 | +2.2% over baseline | Engine optimizations, Fibers |
| PHP 8.2+ | +15% vs 7.4 (Zimuel, 2022) | OPcache improvements |
WordPress running on PHP 8.3 executes PHP code 20-40% faster than the same site on PHP 7.4, with no code changes required (MassiveGRID, 2024). Faster execution means shorter PHP process lifetimes and lower peak memory consumption per request.
If you need to update PHP in WordPress, do it on a staging environment first. PHP 8.x dropped support for several deprecated functions that some older plugins still call, and a compatibility check before the live update avoids downtime.
Sites still on PHP 7.4 should treat updating as part of the same maintenance pass as fixing the memory limit. The PHP version update alone may drop peak memory usage enough to push the site back under the existing server ceiling without touching any other setting.
FAQ on How To Fix The WordPress Memory Limit
What is the WordPress memory limit?
The WordPress memory limit is the maximum RAM a single PHP process can use when your site handles a request.
It is controlled by 3 layers: the server php.ini value, WPMEMORYLIMIT, and WPMAXMEMORY_LIMIT. The server value is always the hard ceiling.
What does "allowed memory size exhausted" mean?
It means a PHP script tried to allocate more memory than the current limit allows. WordPress kills the process immediately and throws a fatal error.
The number shown in the error message is the current limit expressed in bytes, not megabytes.
What is the default WordPress memory limit?
WordPress sets WPMEMORYLIMIT to 40MB for single-site installs and 64MB for multisite by default.
Most hosting providers override this with their own server-level php.ini value, usually between 64MB and 256MB.
How do I check my current PHP memory limit?
Go to Tools > Site Health > Info > Server in your WordPress dashboard. It shows both the WordPress-reported value and the server-enforced PHP memory limit side by side.
Query Monitor also displays per-request memory usage in real time.
How do I increase the WordPress memory limit in wp-config.php?
Open wp-config.php and add this line above the "That's all, stop editing!" comment:
define('WP_MEMORY_LIMIT', '256M');
Save the file and verify the change in Site Health. If the value does not update, the server ceiling is below 256M.
Why does editing wp-config.php not fix the error?
The server php.ini value is the hard cap. WPMEMORYLIMIT can only raise the WordPress limit up to what the server allows.
If the host has set a 128MB ceiling, defining 512M in wp-config.php changes nothing. Fix it via php.ini or the hosting control panel.
What memory limit should I set for WooCommerce or Elementor?
Elementor's stated minimum is 256MB. Running Elementor alongside WooCommerce can push requirements to 512MB or higher.
Set WPMEMORYLIMIT to 512M for WooCommerce stores and verify with Query Monitor that peak usage stays below the limit under normal load.
What is WPMAXMEMORY_LIMIT and when do I need it?
WPMAXMEMORY_LIMIT controls the PHP memory allocation for wp-admin separately from the front end. It defaults to 256MB.
Set it higher when admin-only tasks like bulk updates, media imports, or plugin installations trigger the memory exhausted error.
Can a plugin cause the WordPress memory limit error?
Yes. Page builders, backup tools, security scanners, and poorly coded plugins are the most common causes of PHP memory exhaustion.
Use Query Monitor or the Plugin Memory Usage plugin to identify which plugin consumes the most RAM per request.
How do I stop the memory limit error from coming back?
Set your memory limit 20-30% above your actual peak usage, not just above the error threshold. Run a plugin audit quarterly.
Keeping PHP updated to 8.2 or later also reduces per-request memory consumption compared to PHP 7.4.
Conclusion
This conclusion is for an article presenting a clear path through one of WordPress's most common server-side errors, from reading your current PHP memory limit to fixing the root cause.
Most cases resolve with a single wp-config.php edit. Others need a php.ini change, a hosting panel adjustment, or a direct conversation with your host.
When the limit cannot go higher, the fix shifts to reducing what your site actually consumes. Quarterly plugin audits, switching to PHP 8.2+, and adding object caching via Redis or Memcached all cut per-request memory allocation without touching server settings.
The memory exhausted error is fixable. Pick the method that matches your setup and work through it layer by layer.
