Fix 413 Request Entity Too Large on Hostinger WordPress

You drop a 48MB theme zip or an SQL dump into WordPress, watch the upload bar crawl to 100%, and then get slammed with a raw HTTP 413 Request Entity Too Large error. It’s frustrating because the error doesn’t tell you who rejected it. On Hostinger, that bottleneck could be LiteSpeed, PHP, or WordPress core itself. Here is how I tracked down each layer and fixed it so large uploads actually go through.

The Anatomy of a 413 Error on Hostinger

An HTTP 413 means whatever server or edge proxy received your HTTP POST decided the payload was too fat. As defined in the MDN documentation on 413 Payload Too Large, the client sent more data in the request body than the server was willing to digest.

On Hostinger WordPress sites, three distinct layers can kill your upload:

• The Web Server / Reverse Proxy layer: Hostinger runs LiteSpeed Enterprise. If your request body blows past LiteSpeed’s internal buffer or an edge proxy limit, LiteSpeed terminates the connection before PHP even wakes up.
• The PHP Engine: PHP checks upload_max_filesize and post_max_size from PHP core directives. If your file is 32MB but PHP is capped at 16MB, PHP discards the upload or halts.
• WordPress Core: WordPress enforces its own memory ceiling via WP_MEMORY_LIMIT and checks file sizes against stored site options.

Spotting the culprit is usually straightforward: a plain, unstyled 413 page means LiteSpeed or a reverse proxy killed the request upfront. If you see WordPress’s styled dashboard error saying the file exceeds upload_max_filesize, PHP caught it. We’ll fix both.

Step 1: Increase PHP Limits via Hostinger hPanel

Hostinger configures PHP pools per domain inside hPanel. Don’t waste time hunting for global system config files that get wiped during automated container maintenance—update your pool directly from the dashboard.

1. Log in to hPanel and go to Websites > Manage next to your domain.
2. In the left sidebar, click Advanced > PHP Configuration.
3. Click the PHP Options tab.
4. Update these four directives:

• upload_max_filesize: Set this to 256M (or 512M if you deal with massive site migrations).
• post_max_size: Match or exceed upload_max_filesize. If upload is 256M, make this 256M too.
• memory_limit: Bump to 512M so PHP doesn’t run out of RAM unzipping archives in memory.
• max_execution_time: Raise this from 30 to 300 seconds so slow uploads don’t time out while writing to disk.

Click Save. hPanel applies these changes to your site’s container pool immediately—no server reboot required.

Step 2: Override Directives in .htaccess and .user.ini

hPanel UI settings usually apply cleanly, but they can get clobbered if you have nested configurations or legacy rules lying around. During a staging migration, I ran into an old .htaccess that silently overrode my new dashboard values.

If you’re dealing with subdomains or staging environments, check out our guide on root .htaccess inheritance on Hostinger subdomains to see how rules cascade.

Open public_html/.htaccess via File Manager or SSH. Put these rules at the very top, before the # BEGIN WordPress block:

php_value upload_max_filesize 256M
php_value post_max_size 256M
php_value memory_limit 512M
php_value max_execution_time 300
php_value max_input_time 300

Hostinger runs LiteSpeed, so standard Apache php_value flags work under most setups. But if your PHP version runs via LiteSpeed SAPI (LSPHP) in suEXEC mode, putting php_value in .htaccess can trigger an immediate 500 Internal Server Error. If that happens, remove those lines right away and use a .user.ini file instead.

In your public_html/ directory, create a file named .user.ini:

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

LiteSpeed rescans .user.ini roughly every 5 minutes (300 seconds). If you need it active right now, toggle the PHP version back and forth in hPanel to force worker processes to reload.

Step 3: Define WordPress Upload and Memory Directives

Even when LiteSpeed and PHP accept the incoming payload, WordPress needs enough allocated memory to handle the stream and write it to disk. You set these boundaries in wp-config.php. You can reference the official WordPress wp-config.php documentation for details on these constants.

Open public_html/wp-config.php and add these constants just above /* That's all, stop editing! Happy publishing. */:

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

Why define both? WP_MEMORY_LIMIT governs frontend requests, while WP_MAX_MEMORY_LIMIT is what admin operations get—like unzipping plugins, processing media, and running demo imports. If your page builders choke during asset imports, read our guide on fixing Elementor stuck loading screens via PHP limits and server rules.

Step 4: Bypass LiteSpeed Request Body Buffering

This is where I burned the most time: LiteSpeed’s internal request body buffering. You can set PHP’s upload_max_filesize to 1024M, but if LiteSpeed drops any payload over 50MB, PHP never gets the data. You get slapped with a 413 in about 100ms.

LiteSpeed uses an internal environment flag called noabort to manage long-running request streams. To keep LiteSpeed from aborting large uploads mid-flight, add these directives to the top of your public_html/.htaccess:

 RewriteEngine On RewriteRule .* - [E=noabort:1] RewriteRule .* - [E=noconntimeout:1]

This tells LiteSpeed not to sever upload streams when transfer times exceed its default idle timeout. It’s a lifesaver for users pushing 100MB files over slower internet connections.

Verify Your Limits via WP-CLI and Bash

Don’t just trust that a green switch in hPanel applied your changes. Verify what the runtime is actually seeing over SSH.

SSH into your Hostinger account (credentials are under Advanced > SSH Access in hPanel):

ssh -p 65002 u123456789@195.179.224.12

Navigate to your site root and check the active PHP CLI values:

php -r "echo 'upload_max_filesize: ' . ini_get('upload_max_filesize') . PHP_EOL; echo 'post_max_size: ' . ini_get('post_max_size') . PHP_EOL; echo 'memory_limit: ' . ini_get('memory_limit') . PHP_EOL;"

You should see:

upload_max_filesize: 256M
post_max_size: 256M
memory_limit: 512M

Keep in mind the CLI binary can sometimes use a different configuration than the web pool. To see the exact upload limit WordPress sees in the browser, run this WP-CLI command:

wp eval "echo 'WP Media Limit: ' . size_format(wp_max_upload_size()) . PHP_EOL;"

If that returns WP Media Limit: 256 MB, your PHP pool and WordPress application are on the exact same page.

What Broke When I Pushed to 512MB (Gotchas & Fixes)

When I tested a 380MB database archive on Hostinger, the upload still failed with a 413 even with every single directive set to 512M. Here are the two traps that got me.

1. The Cloudflare / Edge CDN 100MB Wall

If you route traffic through Cloudflare or an external CDN before it reaches Hostinger, your request hits their edge first. Cloudflare’s Free and Pro plans enforce a hard 100MB client_max_body_size limit. If you send a 105MB file, Cloudflare drops it with its own branded 413 error before Hostinger’s LiteSpeed server even sees the packets.

To verify if the CDN is blocking you, bypass it entirely using curl pointed straight to your Hostinger origin IP:

curl -v -F "file=@large-file.zip" http://195.179.224.12/wp-admin/async-upload.php -H "Host: yourdomain.com"

If that upload works without a 413, Cloudflare is your bottleneck. If you can’t bypass the proxy, zip the file into smaller chunks or use SFTP/SSH. If you’re wrestling with massive SQL files, check our tutorial on how to import large WordPress databases via SSH on Hostinger.

2. post_max_size Was Lower Than upload_max_filesize

During my first pass, I bumped upload_max_filesize = 512M but forgot to change post_max_size, leaving it at 128M. When WordPress receives a file upload, the entire HTTP POST body—headers, form metadata, and payload—gets checked against post_max_size.

If post_max_size is smaller than the upload, PHP silently discards $_POST and $_FILES. WordPress gets an empty payload and throws a confusing “Missing a temporary folder” error or triggers a 413. Keep post_max_size equal to or higher than upload_max_filesize. Always.

Frequently Asked Questions

Why does Hostinger still show a 2M or 8M upload limit in the WordPress media library?

If you raised values in hPanel but WordPress still shows 2MB or 8MB, a plugin or active theme is overriding it using the upload_size_limit filter. Disable plugins one by one, or run the WP-CLI eval command above to track down which component is capping the value.

Can I upload files larger than 512MB on Hostinger Shared and Cloud hosting?

Technically you can configure it, but in practice, browser-based HTTP uploads will time out on shared environments. For anything over 512MB, skip the browser: upload the file to wp-content/uploads/ via SFTP or rsync, then register it into the database using wp media import.

Does changing PHP limits in hPanel reboot my entire site?

No. Hostinger reloads the PHP worker pool dynamically. Visitors on the frontend won’t notice downtime or dropped database queries while you save settings.

Will updating WordPress or my theme overwrite my .user.ini file?

No. WordPress core and theme updates only modify files in wp-admin/, wp-includes/, and theme directories. They won’t touch custom configuration files like .user.ini at your site root. However, caching plugins can occasionally rewrite .htaccess, so keep a backup of any LiteSpeed environment flags you put in there.

Next Steps for Hostinger Performance

Now that your server isn’t dropping large payloads, make sure your background tasks don’t bog down your site. Processing media imports and heavy files can trigger runaway background routines that slow down your admin area. To keep things fast, check out our guide on how to replace WP-Cron with a Linux system cron on Hostinger.