How to Increase PHP Memory Limit in WordPress on Hostinger

by Fahim

You activate Elementor, kick off a WooCommerce product import, or run a backup plugin, and boom—white screen with Fatal error: Allowed memory size of 134217728 bytes exhausted. Here is how to bump that ceiling from 128M up to 256M or 512M on Hostinger without breaking your live site.

PHP memory issues crop up because WordPress and PHP maintain two separate limit settings. When one hits a wall, scripts crash immediately. I hit this exact issue last week while importing demo content on a staging build, and fixing it takes less than five minutes once you know which file actually takes precedence.

Close-up of a code editor showing PHP memory limit configuration settings

Why WordPress Hits Memory Limits on Hostinger

WordPress runs on PHP, and every active theme, plugin, DB query, and image upload eats up RAM. Out of the box, core WordPress sets a baseline memory limit of 40MB for single sites and 64MB for multisite setups.

Hostinger configures standard PHP memory limits between 128MB and 512MB depending on your shared, cloud, or VPS tier. Even if your hosting plan supports 512MB, WordPress might still throttle itself at 40MB or 128MB unless you explicitly tell it to use more.

There are two distinct memory settings at play:

PHP memory_limit: The absolute ceiling the PHP runtime allocates to any single script execution across your hosting account.
WP_MEMORY_LIMIT: The software-level limit defined inside WordPress for frontend requests, plus WP_MAX_MEMORY_LIMIT for admin dashboard tasks.

If your server allows 512MB but WordPress caps itself at 64MB, heavy plugins will crash. Flip that around: if you set WordPress to 512MB in wp-config.php while your server-level PHP config restricts accounts to 128MB, your site stays throttled at 128MB.

Method 1: Change PHP Memory Limit in Hostinger hPanel

The quickest way to raise the server-level threshold across all your scripts is through Hostinger’s hPanel. It updates the master PHP configuration without touching a single file.

Log in to hPanel and select your hosting plan.
Go to Advanced > PHP Configuration in the left sidebar.
Click the PHP Options tab at the top.
Scroll down to the memory_limit directive.
Pick your target limit from the dropdown (like 256M, 512M, or 1024M, depending on your plan tier).
Hit Save at the bottom.

Because Hostinger runs LiteSpeed Web Server, PHP worker pools reload dynamically. The change kicks in almost instantly without needing a full web server reboot.

Method 2: Define WP_MEMORY_LIMIT in wp-config.php

Raising the ceiling in hPanel gets PHP ready, but WordPress might still enforce its own internal limits. To give WordPress full access on both the frontend and admin dashboard, tweak your core config file.

Open Hostinger File Manager or connect over SFTP, then open wp-config.php in your root public_html directory.

Drop these two lines right above the comment that says /* That's all, stop editing! Happy publishing. */:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

WP_MEMORY_LIMIT covers standard visitor traffic on the frontend, while WP_MAX_MEMORY_LIMIT gives extra headroom for backend jobs like resizing images, running plugin updates, or processing batch data. For the exact syntax rules, check the WordPress wp-config.php documentation.

Method 3: Update .htaccess on LiteSpeed

Hostinger runs LiteSpeed Web Server on its shared and cloud packages. LiteSpeed handles Apache directives in your .htaccess file, so you can pass runtime environment variables directly to the PHP engine.

Open your public_html/.htaccess file in File Manager and paste this at the very top:

# Increase PHP Memory Limit for LiteSpeed
 php_value memory_limit 512M php_value upload_max_filesize 128M php_value post_max_size 128M php_value max_execution_time 300

If your site throws a 500 Internal Server Error the second you save, your PHP handler doesn’t support runtime php_value flags in .htaccess. Just delete those lines and jump to Method 4 instead.

Method 4: Create or Edit .user.ini in public_html

When PHP runs via FastCGI or LiteSpeed SAPI (LSAPI), user-level INI files take precedence over directory directives. If .htaccess changes get ignored or throw errors, a .user.ini file gets the job done cleanly.

Inside your public_html root directory, check if a .user.ini file already exists. If not, create a new file with that exact name (don’t miss the leading dot).

Add these configuration lines:

memory_limit = 512M
upload_max_filesize = 128M
post_max_size = 128M
max_execution_time = 300
max_input_time = 300

Unlike global php.ini edits, .user.ini directives reload every 300 seconds by default. Take a look at the official PHP memory_limit documentation for details on how PHP evaluates local script allocations across nested folders.

What I Ran and How to Verify the Active Memory Limit

Never trust that a setting took effect just because you saved a file. Always verify what the PHP runtime and WordPress core actually see.

Here is what I ran in my Hostinger SSH terminal to check both CLI and web runtime memory allocations:

# Check PHP CLI active memory limit
php -r 'echo ini_get("memory_limit") . PHP_EOL;'
# Check what WordPress sees via WP-CLI
wp eval 'echo "WP Frontend: " . WP_MEMORY_LIMIT . " | System PHP: " . ini_get("memory_limit") . PHP_EOL;'

If you’re not using SSH or WP-CLI, check it right from the dashboard:

Log in to your WordPress admin panel.
Head to Tools > Site Health.
Click the Info tab and expand the Server section.
Check the PHP memory limit row.
Expand the WordPress Constants section to make sure WP_MEMORY_LIMIT matches what you set.

For more details on debugging hosting bottlenecks, check the official WordPress Site Health Screen guide.

Gotchas I Hit: Hard Server Caps vs Soft WP Limits

While testing these tweaks across different Hostinger tiers, I hit three specific traps that block memory increases from working:

The Plan’s Hard Limit: On entry-level Hostinger Single or Premium plans, the underlying container has hard hardware constraints. If your plan caps out at 512MB, putting 1024M or 2048M in wp-config.php does nothing—you stay locked at 512MB.
Line Placement in wp-config: If you append define( 'WP_MEMORY_LIMIT', '256M' ); at the very bottom of wp-config.php (after require_once ABSPATH . 'wp-settings.php';), WordPress loads all plugins before reading your definition. Keep it up near the top, right after define( 'WP_DEBUG', false );.
Staging Subdomain Overrides: If you use Hostinger’s one-click staging tool, that staging folder has its own .htaccess and .user.ini. You need to apply memory edits to public_html/staging separately.

If you’re moving a site or pointing a custom domain to Hostinger for the first time, check out our guide on how to point Namecheap DNS to Hostinger without breaking email so your records stay intact.

Frequently Asked Questions

What is the recommended PHP memory limit for WooCommerce on Hostinger?

WooCommerce technically asks for 128MB, but 256MB is the real-world baseline once you add gateways, shipping rules, and tracking. If you run a high-traffic store with 1,000+ products, set it to 512MB.

Why is Site Health still showing 128MB after editing wp-config.php?

Because your server-level PHP setting in hPanel or .user.ini is still capped at 128MB. WordPress cannot exceed what PHP allows at the server level. Bump it in hPanel under Advanced > PHP Configuration > PHP Options first.

Can increasing the PHP memory limit slow down my website?

No. Raising the limit doesn’t make PHP consume extra memory on every request. It just raises the ceiling so memory-hungry scripts don’t get killed mid-run.

Will Hostinger reset my memory limits during PHP version upgrades?

Often, yes. When you switch PHP versions in hPanel (say, from PHP 8.1 to 8.3), Hostinger tends to reset the PHP Options tab back to defaults. Always double-check Tools > Site Health after updating your PHP version.

Next Steps for Your Hostinger WordPress Stack

With your memory limits bumped, re-run whatever task triggered the crash—whether that was a batch image regeneration, an XML/CSV import, or an Elementor page update. It should breeze through without fatal errors.

If you run external integrations, webhooks, or background cron workers alongside WordPress, make sure your DNS and timeouts are configured properly so processes don’t stall out downstream.

Related guides on IsItDev