What the WordPress Memory Limit Actually Controls
If you want to increase WordPress memory limit settings, you first need to understand what you are changing. Every time WordPress loads a page, runs a plugin, or processes an image, PHP uses a slice of your server’s RAM for that single request. The memory limit is the ceiling for that slice. Cross it, and PHP stops the request with a fatal error instead of letting it eat the whole server.
By default, WordPress asks PHP for 40MB on a single site and 64MB on a multisite network. That was reasonable years ago. It is not reasonable for a modern site running a page builder, a caching plugin, a form plugin, an SEO plugin, and a security plugin at the same time. A practical starting point for most sites in 2026 is 256MB, with 512MB reserved for admin tasks such as imports, updates, and backups.
One important distinction: WordPress can only request memory up to what your host allows PHP to use. If your hosting plan caps PHP at 128MB, setting 512MB in wp-config.php will not magically give you 512MB. The server limit always wins. That is why checking first, then raising the limit in the right place, matters.
How to Tell If You Have Hit the Memory Limit
The classic symptom is a white screen or a fatal error message that looks like this:
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes)
The number 134217728 is 128MB in bytes. The message tells you the limit that was hit, not necessarily which plugin caused it. The file named at the end of the error is simply where the last allocation failed; the real cause is usually the total memory used across the whole request.
Memory errors also show up in less obvious ways. A media upload that fails halfway through, an import that stops partway, a page-builder save that spins forever, or a plugin update that dies mid-process can all be memory problems. Before you change anything, confirm the current limit in Tools > Site Health > Info > Server, where WordPress lists the PHP memory limit it is actually running with.
Before You Change Anything: Back Up First
You are about to edit wp-config.php, a file that can take your whole site down if it contains a syntax error. Download a copy of it first, or make sure you have a recent backup you can restore from your hosting panel. Edit with a plain-text editor, never a word processor, and add each line exactly as shown. If you already have a WP_MEMORY_LIMIT line in the file, edit that line instead of adding a second one — duplicate definitions cause confusion and, in some setups, warnings.
Method 1: Increase WordPress Memory Limit in wp-config.php
This is the method to try first. It affects WordPress only, it needs no server restart, and it works on most shared hosting plans. Connect with your host’s file manager or an FTP client, open wp-config.php in your site’s root folder, and add these lines just above the comment that reads “That’s all, stop editing! Happy publishing.”:
define( 'WP_MEMORY_LIMIT', '256M' ); define( 'WP_MAX_MEMORY_LIMIT', '512M' );
WP_MEMORY_LIMIT controls normal front-end requests. WP_MAX_MEMORY_LIMIT controls admin-side work such as plugin updates, media processing, and imports, which legitimately need more headroom. Save the file, clear any server or caching-plugin cache, then recheck Tools > Site Health > Info > Server. If the number has not moved, your host is enforcing a lower server-level cap, and you need Method 2 or a word with support.
Method 2: Raise the PHP Limit in php.ini or Your Hosting Panel
If wp-config.php alone does not raise the limit, change the server-level PHP setting. In cPanel, open Software > MultiPHP INI Editor, select your domain, and set memory_limit to 256M. In Hostinger’s hPanel, the same setting lives under PHP Configuration. If you have direct access to php.ini, the line is:
memory_limit = 256M
This is the stronger fix because it raises the ceiling WordPress is allowed to request. On most shared hosts it takes effect immediately, though some panels ask you to save and wait a minute for the new PHP configuration to apply. After changing it, verify again in Site Health — never assume a panel save worked.
Method 3: Use .htaccess on Apache Servers
On Apache hosting, you can also set the limit in the .htaccess file in your site’s root. Back the file up first, then add this line:
php_value memory_limit 256M
This method only works when PHP runs as an Apache module. On many modern hosts PHP runs as CGI or PHP-FPM, in which case php_value lines are ignored or can trigger a 500 error. If your site breaks immediately after adding the line, remove it and use Method 1 or 2 instead. On Nginx servers, .htaccess is not used at all, so this method does not apply.
How Much Memory Does Your Site Actually Need?
More is not always better. Raising the limit hides the symptom; it does not fix a plugin that leaks memory or a theme that loads everything on every page. Use these ranges as a starting point, then adjust based on what Site Health and your error log show:
- Simple blog or brochure site: 128MB to 256MB is usually plenty.
- Page-builder site with several plugins: 256MB front-end, 512MB admin.
- WooCommerce or membership site: 256MB to 512MB, sometimes higher for large imports.
- Multisite or agency hosting: 512MB and up, set per site need rather than globally.
If you raise the limit and the error returns within days, stop raising it and start investigating. Deactivate plugins one at a time and repeat the action that failed, or check your error log for a plugin that appears repeatedly. A limit of 512MB that still exhausts itself is a code problem, not a configuration problem.
Fix the Root Cause, Not Just the Number
Three habits keep memory usage under control over time. First, audit plugins regularly: deactivate anything you no longer use, and replace two overlapping plugins with one where you can. Second, optimise images before upload — a 5MB photo straight from a camera costs memory on every resize and thumbnail generation. Third, keep WordPress, PHP, and your plugins updated; newer PHP versions handle memory more efficiently, and plugin updates often fix the exact leak that was pushing you over the edge. If you are still on PHP 7.4, upgrading to a supported PHP 8.x release (after testing on staging) is worth more than another 128MB of headroom.
For related performance work, see my guides on improving Largest Contentful Paint in WordPress and speeding up the WordPress admin dashboard — both cover the plugin and asset bloat that usually sits behind memory problems.
When to Ask Your Host Instead
Contact your host when the limit does not change after editing wp-config.php and php.ini, when your panel offers no PHP settings at all, or when you need more than your plan allows. Ask specifically: “What is the maximum PHP memory_limit available on my plan, and can it be raised to 256MB?” That question gets a faster, clearer answer than “my site is slow.” If the answer is no, that is a real signal your plan no longer fits your site, and upgrading the plan beats endlessly editing config files.
For the official reference on the constants used above, see the WordPress developer handbook on editing wp-config.php, and Hostinger’s walkthrough on increasing the WordPress memory limit.
Quick Recap
- Confirm the current limit in Tools > Site Health > Info > Server.
- Back up wp-config.php, then set WP_MEMORY_LIMIT to 256M and WP_MAX_MEMORY_LIMIT to 512M.
- If nothing changes, raise memory_limit to 256M in php.ini or your hosting panel.
- Use .htaccess only on Apache with mod_php, and remove it at once if it causes a 500 error.
- If errors return after a raise, audit plugins and images instead of raising the limit again.
A memory limit error feels alarming, but it is one of the most fixable WordPress problems. Ten minutes of careful config work usually ends it — and the plugin audit that follows often makes the whole site faster, not just error-free. If your WordPress site keeps hitting limits or slowing down under real traffic, get in touch and I can take a look at what is actually eating the memory.