The need to increase WordPress memory limit arises when PHP runs out of the allocated server memory during a WordPress page request and either crashes the request silently (producing a white screen or 500 error) or displays the explicit error: “Fatal error: Allowed memory size of X bytes exhausted.” PHP’s memory limit is a safety valve designed to prevent runaway scripts from consuming all available server memory — but on shared hosting plans with low defaults, or on sites that have grown in complexity since they were set up, the default limit becomes a recurring constraint rather than a safety guard. Learning to increase WordPress memory limit correctly — and understanding which configuration method works on which hosting environment — is one of the practical WordPress maintenance skills that saves hours of troubleshooting time. This guide covers every method to increase WordPress memory limit from the WordPress-native approach through to the server-level configurations that override everything else, with honest guidance on what to do when the hosting plan itself is the limiting factor. If you want the full context, see our Complete Guide to WordPress How.
Understanding the WordPress Memory Limit — What the Values Actually Mean
PHP memory limits are expressed in megabytes and control the maximum memory a single PHP process can use during a request. WordPress adds its own memory limit configuration on top of PHP’s, which means there are actually two values that can affect the outcome when you increase WordPress memory limit: the PHP-level limit set by the server, and the WordPress-level limit requested by WordPress within that PHP ceiling.
| Memory Limit Value | Typical Use Case | Notes |
|---|---|---|
| 32M | Minimal shared hosting default | Insufficient for any WordPress site with plugins; immediately increase WordPress memory limit |
| 64M | Common shared hosting default | Adequate for minimal sites; fails on WooCommerce, page builders, and multi-plugin setups |
| 128M | WordPress’s own recommended minimum | Workable for most basic sites; some WooCommerce operations still exhaust it |
| 256M | Recommended for sites with WooCommerce, page builders, or many plugins | Covers the vast majority of production WordPress installations |
| 512M or higher | Large WooCommerce stores, complex multisite, heavy import operations | Necessary for resource-intensive operations; requires adequate server-level support |
WordPress itself defines two memory-related constants. WP_MEMORY_LIMIT is the memory WordPress requests for front-end requests — the amount allocated for serving pages to visitors. WP_MAX_MEMORY_LIMIT is the memory WordPress requests for admin panel operations — things like bulk plugin updates, image regeneration, and import operations that require more memory than a simple page load. When you increase WordPress memory limit via wp-config.php, you are setting how much memory WordPress requests — but the actual available memory is still capped by the PHP-level limit set by the server. If the server’s PHP limit is 128M and you set WP_MEMORY_LIMIT to 256M, WordPress requests 256M but PHP only allocates up to 128M.
The full picture of memory available to WordPress on a given request is: min(WP_MEMORY_LIMIT, php_memory_limit). To increase WordPress memory limit beyond what the PHP configuration allows, both values need to be raised — the WordPress constant and the PHP limit itself. The methods to increase each are different, and some hosting environments restrict changes to the PHP-level limit regardless of what WordPress requests.
Increase WordPress Memory Limit via wp-config.php — The Fastest Method
The wp-config.php approach is the first thing to try when you need to increase WordPress memory limit because it requires access to only one file, takes effect immediately, and works on the majority of shared and managed hosting environments. It is the WordPress-native method — WordPress reads these constants at startup and requests the specified memory from PHP.
- Connect to your server via FTP or open the hosting file manager and navigate to the WordPress root directory
- Download wp-config.php and open it in a text editor (Notepad++, VS Code, or any plain text editor — never a word processor)
- Find the line that reads “That’s all, stop editing! Happy publishing.” and add the following lines directly above it:
define( 'WP_MEMORY_LIMIT', '256M' ); define( 'WP_MAX_MEMORY_LIMIT', '512M' );
- Save the file and upload it back to the server, overwriting the existing wp-config.php
- Verify the change took effect: navigate to Tools → Site Health → Info → Server in the WordPress admin and look at the PHP Memory Limit row. If it shows 256M (or the value you set), the wp-config.php change worked. If it still shows the old lower value, the server’s PHP configuration is overriding the WordPress request.
- Test the operation that was previously triggering the memory exhaustion error to confirm it now completes successfully after you increase WordPress memory limit
The 256M value for WP_MEMORY_LIMIT covers the vast majority of front-end memory requirements for complex WordPress sites. The 512M value for WP_MAX_MEMORY_LIMIT accommodates heavy admin operations. If Site Health still shows the old limit after this change, the hosting plan has set an absolute PHP memory ceiling that the wp-config.php approach cannot override — proceed to the php.ini method or contact your host.
Increase WordPress Memory Limit via php.ini and .htaccess
When the wp-config.php method does not take effect because the server’s PHP configuration overrides it, the next layer to try to increase WordPress memory limit is the PHP configuration itself. Two approaches are available depending on what the hosting environment allows: editing php.ini directly, or using .htaccess PHP directives.
For the php.ini approach: create a file named php.ini in the WordPress root directory (the same folder as wp-config.php) and add:
memory_limit = 256M
Save and upload. On hosting environments that support per-directory php.ini files (common on cPanel shared hosting), this setting overrides the server’s default for requests processed from that directory. Reload the WordPress admin and check Tools → Site Health → Info → Server → PHP Memory Limit to confirm the change registered. If it has not changed, the hosting environment does not support per-directory php.ini files and this approach will not work to increase WordPress memory limit.
For the .htaccess approach on Apache servers: open the .htaccess file in the WordPress root (enable hidden files first) and add this line above the WordPress default rewrite block:
php_value memory_limit 256M
This sets the PHP memory limit via Apache’s per-directory configuration. It works on Apache with mod_php. On servers using PHP-FPM or FastCGI, .htaccess PHP directives are ignored — the per-directory php.ini method or direct php.ini editing is required instead. Test after adding the directive to confirm the memory limit has changed in Site Health. If a 500 Internal Server Error appears after adding the .htaccess line, the server configuration does not allow PHP value overrides via .htaccess — remove the line and use an alternative method to increase WordPress memory limit.
When the Hosting Plan Sets an Absolute Memory Cap
Some hosting environments — particularly very low-cost shared hosting plans — enforce a PHP memory limit at the server infrastructure level that cannot be overridden through wp-config.php, php.ini, or .htaccess. The WordPress memory limit requested through these methods is silently capped at the hosting provider’s maximum, regardless of what value is specified. When every configuration method shows no change in the Site Health memory limit value, this is the most likely explanation.
The steps to confirm the hosting plan is the limiting factor and to resolve it: contact your hosting provider’s support team and explicitly ask what the maximum PHP memory limit available on your plan is, and whether it can be increased. State that you are encountering memory exhaustion errors on a WordPress site and need at minimum 256M PHP memory. Most hosting providers that advertise WordPress hosting will either increase the limit at no charge or offer a plan upgrade that includes a higher limit. A provider that cannot offer at least 128M PHP memory is providing a plan that is technically underspecified for a functional WordPress installation with plugins — this is a signal that the plan is inappropriate for the site’s needs regardless of its price point.
On VPS and dedicated servers where you have access to the main php.ini file (typically at /etc/php/8.x/fpm/php.ini or a similar path depending on PHP version and server configuration), edit the memory_limit line directly in this file and restart the PHP process (sudo systemctl restart php8.x-fpm). This is the definitive method to increase WordPress memory limit to any value supported by the server’s available RAM, without any configuration ceiling imposed by a hosting provider’s per-plan restrictions.
Diagnosing Actual Memory Usage Before Increasing the Limit
Increasing the memory limit is the correct fix for memory exhaustion errors — but understanding what is consuming that memory is equally important. Simply raising the limit addresses the immediate symptom; identifying the memory-intensive component addresses the cause. A plugin with a memory leak will eventually exhaust even a 512M limit if the underlying code inefficiency is not addressed.
Tools and approaches for diagnosing memory usage before and after you increase WordPress memory limit:
- Query Monitor plugin: Installs in the WordPress admin bar and shows memory usage per page request, hook execution times, and database query counts. The memory usage figure in the admin bar after each page load shows exactly how much memory the current configuration requires — useful for confirming that the new limit provides adequate headroom
- WP_DEBUG log: Memory exhaustion errors appear in the debug log with the specific file where PHP ran out of memory. The file path often points directly to the plugin whose code pushed memory over the limit
- Plugin deactivation testing: Deactivate plugins one at a time and check the memory usage reported by Query Monitor after each deactivation. A plugin whose deactivation reduces memory usage by 30MB or more is contributing disproportionately to the total and is worth investigating for memory optimisation or replacement
- Site Health: Tools → Site Health → Info → Server shows the current PHP memory limit alongside other server configuration values — the baseline reference for confirming whether your attempt to increase WordPress memory limit has taken effect
WooCommerce and Page Builder Memory Requirements
WooCommerce and page builder plugins like Elementor, Divi, and WPBakery are the two categories of WordPress plugins most consistently responsible for the need to increase WordPress memory limit significantly above the default. Understanding their memory footprint helps set appropriate limits proactively rather than reacting to memory exhaustion errors after they start affecting visitors.
WooCommerce’s base memory requirements are higher than typical plugins because it loads product catalogue data, customer session information, shipping calculation libraries, payment gateway integrations, and tax calculation modules on relevant pages. A basic WooCommerce installation with a few products requires approximately 64–128M for front-end requests. A large WooCommerce store with hundreds of products, multiple payment gateways, subscription functionality, and several WooCommerce extension plugins can require 256M or more on product archive and checkout pages. If the need to increase WordPress memory limit appeared after installing or expanding WooCommerce, 256M should be the immediate target value.
Page builders are memory-intensive because they load their entire framework — layout engine, widget library, template system, and asset manager — on every page load, regardless of whether the page uses complex builder features. Elementor, for example, loads significantly more memory than a well-coded custom theme for an equivalent page design. When both WooCommerce and a page builder are active simultaneously, the combined memory footprint often requires 256M to 512M to operate without exhaustion errors during peak load. Setting WP_MEMORY_LIMIT to 256M and WP_MAX_MEMORY_LIMIT to 512M covers the front-end and admin requirements for most WooCommerce-plus-page-builder configurations and eliminates the need to repeatedly increase WordPress memory limit as the site grows.
Our guide on fixing the WordPress memory exhausted error covers the specific error messages that indicate memory exhaustion and the diagnostic process for identifying whether the wp-config.php approach or a server-level change is needed to increase WordPress memory limit in a specific hosting environment. Our guide on how to optimise WordPress performance covers memory usage in the context of the broader server-side performance optimisation stack. The WordPress wp-config.php developer documentation lists every available constant including the memory limit options, their accepted values, and their interactions — the definitive reference for understanding exactly what each constant does when you increase WordPress memory limit through wp-config.php. Related: How to Disable WordPress Plugins Safely Fast With Reliable Methods.
