How to Increase the WordPress Memory Limit

What the memory exhausted error is telling you

The error means PHP hit its memory_limit while running WordPress. Raise memory_limit to 256M in cPanel's MultiPHP INI Editor first, then set define('WP_MEMORY_LIMIT', '256M') in wp-config.php above the stop-editing line. A WordPress value above the PHP value is ignored, so the panel change is the one that counts.

The full message names the file and line: Allowed memory size of 268435456 bytes exhausted, tried to allocate 2048 bytes, in a specific .php file. That path is the lead worth following, because it names the plugin or theme that ran out, not the page that happened to load.

• A single request — a backup plugin zipping files, an image being resized, an import running. The site recovers once the request ends.
• Every admin page — a heavy page builder or a plugin loading a full table into memory on every load.
• Only during cron — a backup or update task scheduled at a busy hour.

WordPress has two memory values, and PHP has a third

Three numbers decide what a request may use, and only the smallest of them applies. Most guides name one or two and leave readers wondering why the new value did nothing.

WordPress can lower the ceiling for its own requests but cannot raise it above memory_limit. So a wp-config line of 512M on a server capped at 128M changes nothing, and the error repeats after a reload. Fix the PHP value first, then the WordPress one if you want the front end to use memory faster.

Method 1: raise memory_limit in cPanel

This is the change that lifts the real ceiling on shared hosting, and it survives plugin updates and theme changes.

1. Log in to cPanel and open Software, then MultiPHP INI Editor.
2. Select the domain, then find memory_limit in Basic Mode.
3. Set it to 256M. Use 512M only when a page builder, WooCommerce and a backup plugin all run on the same site.
4. Click Apply, then open Tools, Site Health, Info, Server in wp-admin and read PHP memory limit.

You know it worked when Site Health reports the new number and the page that failed before loads without the error. If the panel refuses the value, the host has capped it at server level and only support can move it.

Method 2: set WP_MEMORY_LIMIT in wp-config.php

Use this when the error appears on the front end while the admin works, which means PHP has room and WordPress is limiting itself.

1. Open File Manager and edit wp-config.php in public_html, or download it over FTP and edit locally.
2. Find the line /* That's all, stop editing! Happy blogging. */ and add the definitions above it.
3. Add define( 'WP_MEMORY_LIMIT', '256M' ); and, for admin and cron, define( 'WP_MAX_MEMORY_LIMIT', '512M' );
4. Save and reload. A syntax error here returns a white screen, so keep a copy of the file before editing.

Placement matters. A definition after the stop-editing line is still parsed, but a plugin that has already read the constant wins, and you will spend an hour wondering why the number did not move. If the file already defines WP_MEMORY_LIMIT, edit the existing value rather than adding a second line.

Method 3: .user.ini or .htaccess, depending on how PHP runs

On PHP-FPM, which most cPanel servers use today, a .user.ini file in public_html is the override that works. One line is enough: memory_limit = 256M. Save it as plain text at 644 and wait up to five minutes for PHP's ini cache to expire.

On an older server running PHP as an Apache module, php_value memory_limit 256M in .htaccess does the same job. On FPM that same line returns 500 on every page, because Apache does not recognise the directive. If the site breaks right after you save, remove the line before you do anything else.

If neither file changes the number that Site Health reports, the account has a host-level cap and the file is being overruled. That is a support request, not a syntax problem.

Find the plugin that is actually eating the memory

A higher limit buys time, not a fix. Something is allocating hundreds of megabytes, and the error message or a profiler names it.

• The error path — the file in the message points at a plugin folder. Start there, and check whether an update is available.
• Query Monitor — its admin panel shows peak memory per page and per plugin, which turns a guess into a name.
• Deactivate in halves — disable half the plugins, test, then the other half. Four rounds identify the culprit on a site with twenty plugins.
• Backups and imports — these jobs are the usual cause. Run them at night, and prefer a host-side backup over a PHP one on a small plan.

Image handling is the other common cost: WordPress generates several sizes per upload, so a 6000 pixel photo can spike memory on its own. Uploading 2000 pixel images and letting the theme scale them saves both memory and page weight.

Which number to choose

Do not set a gigabyte to make an error disappear. Pick the smallest value that clears the job and leaves room for traffic.

After the change, watch the Site Health figure for a week. If peak usage sits near the new ceiling on ordinary pages, the issue is code, not the limit.

When the cap belongs to the host

On WordPress hosting here the panel exposes memory_limit, so Method 1 works without a ticket. If the field is greyed out or the value reverts, email support@webji.services with the domain, the current figure and the error line. Support is 24/7 by email in Hindi and English, with an average first reply under 60 minutes.

Two related limits usually move together with this one: the upload ceiling in the upload size guide, and the PHP version itself. Both sit in the same panel screen on a cPanel account.