Increase WordPress Memory Limit: Find the Limit That Applies

To increase a WordPress memory limit, first confirm which limit is stopping the task. WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT are WordPress requests to PHP, not additional memory allocations. The effective memory_limit, the host’s restrictions and available server capacity determine what the workload can actually use.

Start with the error. An Allowed memory size ... exhausted message supports investigating a PHP allocation limit. A timeout, failed upload or 502 response can have a different cause. If the whole site is down, use the WordPress critical-error recovery guide to regain access and collect a private log first.

The settings describe different things

PHP documents memory_limit and max_memory_limit. In WordPress, wp_initial_constants() defines the constants and attempts the initial increase. It does not reduce an already higher PHP limit to the lower WordPress value.

For example, WordPress’s default WP_MEMORY_LIMIT can be 40M on a single site when the setting is changeable, while PHP already allows 256M. Seeing 40M in a constants list does not establish that PHP is restricted to 40 MB. Multisite and unchangeable settings have different initialization paths.

wp_raise_memory_limit() attempts a further increase for contexts such as administration, image processing and cron. Filters can affect those requests. It raises rather than lowers the existing limit, and it can fail if the setting cannot change.

1. Record the failing operation and the current values

In WordPress, open Tools → Site Health → Info. Record the PHP memory limit under Server, any separate admin-screen value, plus WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT under WordPress Constants. WordPress can report the initial PHP limit separately from the raised admin limit in its Site Health server data. Compare these with the PHP settings for the exact domain in your hosting panel.

Record the operation too: saving an Elementor page, generating an image, updating a plugin, processing an import or running a scheduled job. Include the timestamp, error and component version. The downloadable memory check record keeps those observations together.

Site Health is a reading from its own admin request. A queue worker, WP-CLI command, separate subdomain or scheduled system job can run with a different configuration. Ask the host to check the context of the failure rather than assuming one screenshot describes every process.

A maintainer with WP-CLI can record the CLI environment without exposing a public diagnostic file:

wp --path=/absolute/path/to/wordpress eval 'printf("SAPI=%s PHP=%s memory_limit=%s WP_MEMORY_LIMIT=%s WP_MAX_MEMORY_LIMIT=%s\n", PHP_SAPI, PHP_VERSION, ini_get("memory_limit"), WP_MEMORY_LIMIT, WP_MAX_MEMORY_LIMIT);'

Replace the path. This loads the site’s WordPress code, so use it only on an installation you administer. It reports CLI, not the web worker that served a failing editor request. WP-CLI documents wp eval; its output is a useful comparison, not evidence that a web setting took effect.

Our PHP Version Checker observes public version clues. It cannot read a private memory setting, installed package revision or worker configuration.

2. Change one appropriate setting

Take a configuration backup and use staging where available. Check the requirements of the component and agree a finite target with the host. Do not choose a value merely because another site’s tutorial used it.

If WordPress’s requested values need increasing and the host permits that change, edit the existing definitions in wp-config.php before WordPress loads. For example:

// Example only: use values approved for this site's workload and hosting.
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '256M' );

These example values are not a recommendation for every WordPress site. Do not add a second definition of an existing constant. Use straight quotes, retain the original credentials and keys, and avoid replacing the entire file. WordPress’s configuration guide explains where these settings belong. Our wp-config generator can help prepare an individual snippet.

If the effective PHP value stays lower, the next change belongs in the hosting configuration, not in repeated copies of that snippet. Use the provider’s PHP settings interface or ask support which file and scope it manages.

For a host that explicitly supports a per-directory PHP configuration, the setting may look like:

memory_limit = 256M

Do not paste it into every possible file. PHP’s .user.ini documentation limits that mechanism to CGI/FastCGI and describes configuration caching. An .htaccess PHP directive is not portable to every PHP-FPM or Nginx setup. Ask the provider which mechanism applies and when a change becomes active.

3. If the change does not take effect, follow the evidence

A reproducible host-lock mismatch

Consider a worked configuration example, not a measurement of a client site:

PHP-FPM pool:       php_admin_value[memory_limit] = 128M
wp-config.php:     WP_MEMORY_LIMIT = 256M
wp-config.php:     WP_MAX_MEMORY_LIMIT = 256M
Expected PHP limit after WordPress requests an increase: 128M

The constants can still contain 256M. The PHP-FPM administrator setting prevents an ini_set() override, as specified in PHP’s pool configuration reference. That is why a constants screenshot can look successful while the operation still has the lower limit.

A developer can reproduce this on a disposable staging pool with those explicit settings, then compare Site Health before and after the host changes the pool restriction and performs the required reload. Do not lower a live site’s working limit to recreate the example. Record the observed effective value each time and compare it with the configured constants.

4. Retest the operation, not just the settings page

Use the same operation and a representative bounded input on staging, with outgoing emails, payments and webhooks routed to appropriate test destinations. For example, retry the same editor save or the same import batch after changing only the agreed limit.

Record whether it completed, the time and any new log message. Where available, ask the maintainer to measure peak memory in that task and context. Do not infer that the task used the entire configured limit simply because it completed.

If the failure remains, investigate the code path. A large image may need different handling from a bulk import. An import may need smaller batches. A repeated recursive call needs a code repair. Elementor’s memory requirements are relevant to that component, but meeting a published baseline does not explain every editor failure.

Keep the change if it solves the intended task within the host’s capacity and passes the site’s important checks. Otherwise restore the previous setting and retain the error evidence for the next diagnostic step.

More memory per request does not create more workers

On PHP-FPM, pm.max_children limits simultaneous served requests. A provider can also enforce total account or container memory. Raising one script’s allowance does not increase either capacity. PHP’s FPM reference documents the worker limit.

A pool handling several memory-heavy tasks at once needs capacity for their actual resident memory plus the rest of the stack. Database, cache and operating-system use still matter. Multiplying a configured memory_limit by worker count is not a complete RAM-sizing formula: actual use, shared memory and allocations outside PHP’s tracking differ. Ask the host to measure the workload and concurrency before changing worker settings.

If the original problem is slow database work, exhausted workers or a loop in application code, a larger memory allowance can leave that cause unresolved.

October 2026 PHP changes: keep security and tuning separate

Current security releases distinguish the normal memory limit from a hard termination boundary. Crossing the hard boundary can stop a worker without the usual WordPress shutdown logging. Exit status 137 alone also does not distinguish PHP’s hard limit from an operating-system or container kill; inspect the worker’s stderr. PHP documents the new behavior.

memory_limit = -1 removes the normal allocation limit. It is not a general WordPress performance fix or a substitute for applying the available PHP security update. A temporary measure discussed in an advisory has a different purpose from choosing a production memory budget. Coordinate security measures with the host, and use the current PHP security notice for the maintained patch guidance.

Get help with the failing WordPress task

Send the operation, timestamp, redacted error, Site Health values and hosting provider. Our Website Fix Sprint can cover an agreed troubleshooting priority after assessment. We confirm the scope, price and timeline before starting.

If the issue followed a PHP change or needs a supported runtime update, the WordPress PHP update service covers the available update scope and host coordination. Compatibility repairs are quoted separately.

Get help with my WordPress memory error