How to Fix “WordPress Download File Instead of Opening in Browser” (8 Fixes)

TL;DR: When WordPress downloads an index.php file instead of loading your site, the cause is almost always a PHP handler misconfiguration, a corrupted .htaccess file, or a cache plugin conflict. The fastest fix is to check your PHP version in cPanel’s MultiPHP Manager, then reset .htaccess to the WordPress default. Below are 8 proven fixes covering Apache, Nginx, Cloudflare, and malware scenarios.

I’ve dealt with this error more times than I’d like to admit — both on my own sites and while helping friends troubleshoot theirs.

You type in your domain, hit enter, and instead of your WordPress site loading normally, your browser downloads a file called index.php. You’re left staring at a blank page with a random file sitting in your Downloads folder.

The first time it happened to me, I panicked. I thought my site was hacked. Turns out, my hosting provider had quietly updated their PHP version and my .htaccess file was still referencing the old one. A 30-second fix once I knew what to look for.

In this guide, I’ll walk you through every cause of this error and exactly how to fix each one — whether you’re on shared hosting with cPanel, a VPS running Nginx, or using Cloudflare as a CDN. If you’re still getting started with WordPress, don’t worry — I’ll keep the steps clear and beginner-friendly.

Why Does WordPress Download a File Instead of Loading?

When you visit a WordPress site, your web server (Apache or Nginx) is supposed to hand the index.php file to the PHP interpreter, which processes it and sends back an HTML page to your browser.

When that chain breaks — when the server doesn’t know how to process .php files — it treats the file as a static download instead. Your browser receives it with a Content-Type header like application/octet-stream instead of text/html, and dutifully downloads it.

Here are the specific causes:

Now let’s fix each one.

Fix 1: Check Your PHP Handler Configuration

This is the #1 cause and the fix I reach for first every single time. When your hosting provider upgrades PHP (say from 7.4 to 8.1), the handler directive in your .htaccess file may still reference the old version. Since that version no longer exists on the server, Apache doesn’t know how to process .php files anymore.

As of February 2026, 42.9% of WordPress sites still run PHP 7.4 — a version that reached end-of-life in November 2022. When hosts finally force-upgrade these sites, the download-instead-of-open error is one of the most common results.

How to Fix It in cPanel

1. Log into cPanel
2. Go to Software → MultiPHP Manager
3. Check which PHP version is assigned to your domain
4. If it says something outdated (PHP 7.4 or lower), select your domain and switch to PHP 8.1 or 8.2
5. Open your .htaccess file and look for old handler lines like:

AddHandler application/x-httpd-php74 .php
AddHandler application/x-httpd-php56 .php

If you find lines like these, remove them. The correct cPanel-generated handler should look like this:

# BEGIN cPanel-generated handler, do not edit
AddHandler application/x-httpd-ea-php81 .php .php81 .phtml
# END cPanel-generated handler

After making changes, reload your site. In most cases, this alone solves the problem.

Fix 2: Reset Your .htaccess File

The .htaccess file controls how Apache handles URL routing in WordPress. If it gets corrupted — through a bad plugin update, a manual edit, or malware — WordPress can break in all sorts of ways, including the download-instead-of-open error.

Here’s how to reset it to the WordPress default:

1. Connect to your server via FTP/SFTP (using FileZilla or similar) or use cPanel File Manager
2. Navigate to your WordPress root directory (usually public_html)
3. Enable “Show Hidden Files” in your file manager settings (dotfiles are hidden by default)
4. Download a backup of the current .htaccess file to your computer
5. Delete all the contents of .htaccess and paste this default WordPress code:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Save the file and visit your site. If it loads normally, the old .htaccess was the problem.

Fix 3: Remove AddHandler/AddType Directives

Sometimes the .htaccess file doesn’t need a full reset — it just has stale AddHandler or AddType lines that reference PHP versions no longer installed on the server.

Open your .htaccess file and search for any lines like these:

AddHandler application/x-httpd-php5 .php
AddHandler application/x-httpd-php52 .php
AddHandler application/x-httpd-php54 .php
AddHandler application/x-httpd-php56 .php
AddHandler application/x-httpd-php70 .php
AddHandler application/x-httpd-php71 .php
AddHandler application/x-httpd-php74 .php
AddType application/x-httpd-php .php

Comment them out by adding # at the beginning of each line, or delete them entirely. Save the file and test your site.

If you’re not sure which handler line is correct for your server, leave it to cPanel’s MultiPHP Manager — it will auto-generate the right one (see Fix 1).

Fix 4: Deactivate Cache Plugins

Cache plugins like WP Super Cache, W3 Total Cache, WP Fastest Cache, and WP Rocket write their own rules into .htaccess. After a PHP version change or a plugin update, these rules can conflict with the server configuration and trigger the download error.

If You Can Access wp-admin

1. Go to Plugins → Installed Plugins
2. Deactivate your caching plugin
3. Visit your site’s front end. If it loads, the cache plugin was the culprit
4. Either reconfigure the plugin or switch to a different caching solution

If wp-admin Is Also Broken

When the entire site is affected, wp-admin usually won’t load either. Here’s how to deactivate plugins without dashboard access:

Method 1 — Via FTP/File Manager:

1. Navigate to /wp-content/plugins/
2. Rename the cache plugin folder (e.g., wp-super-cache → wp-super-cache.disabled)
3. WordPress will automatically deactivate it since the folder no longer matches
4. Test your site

Method 2 — Via phpMyAdmin (deactivates ALL plugins):

1. Open phpMyAdmin from your hosting panel
2. Select your WordPress database
3. Open the wp_options table
4. Find the row where option_name = active_plugins
5. Change the option_value to a:0:{}

This deactivates every plugin at once. If your site loads after this, re-enable plugins one at a time until you find the one causing the issue.

Fix 5: Check File Permissions

Incorrect file permissions can prevent the server from executing PHP files. WordPress has specific permission requirements:

If you have SSH access, run these commands to fix permissions across your entire WordPress installation:

# Fix directory permissions
find /path/to/wordpress/ -type d -exec chmod 755 {} \;

# Fix file permissions
find /path/to/wordpress/ -type f -exec chmod 644 {} \;

# Secure wp-config.php
chmod 640 /path/to/wordpress/wp-config.php

Replace /path/to/wordpress/ with your actual WordPress root path (usually /home/username/public_html/).

Fix 6: Scan for Malware

If none of the above fixes worked, malware could be the cause. Hackers frequently inject obfuscated code into .htaccess, wp-config.php, and theme files like header.php or functions.php.

According to Patchstack’s 2025 security report, 7,966 new vulnerabilities were discovered in the WordPress ecosystem in 2024 — a 34% increase over 2023. And WordPress sites get attacked every 32 minutes on average.

Here’s how to check for malware:

1. Verify WordPress core files — if you have WP-CLI installed, run wp core verify-checksums. This compares your core files against the official WordPress.org checksums. Any modified files will be flagged
2. Check .htaccess for injected code — look for base64_decode, eval(, or obfuscated strings that look like random characters
3. Review wp-config.php — make sure there are no unfamiliar require or include statements at the top or bottom
4. Install Wordfence — run a full malware scan from Wordfence → Scan. It checks all WordPress files, themes, and plugins against known malware signatures
5. Check recently modified files — via SSH, run find /path/to/wordpress/ -mtime -7 -type f to list all files modified in the last 7 days

If malware is confirmed, the cleanest approach is to reinstall WordPress core. Go to your WordPress dashboard → Updates → Re-install Now. This replaces all core files without touching your wp-content folder (themes, plugins, uploads are safe). For more on keeping your WordPress site secure and running at peak performance, proper server configuration is essential.

Fix 7: Cloudflare and CDN Settings

This one surprised me the first time I encountered it. If your site is behind Cloudflare or another CDN, the proxy layer can sometimes interfere with how PHP files are served.

Cloudflare-specific fix:

1. Log into your Cloudflare dashboard
2. Go to Speed → Optimization
3. Look for Automatic Signed Exchanges (SXGs) — disable it
4. Purge the Cloudflare cache (Caching → Purge Everything)
5. Test your site

Cloudflare’s SXG feature can cause browsers to download pages instead of rendering them. Multiple reports in the Cloudflare community forums confirm this. Disabling SXG and purging the cache fixes it immediately.

Also check your Page Rules — if you have a rule that sets Cache Everything without excluding PHP files, that can cause the same behavior. If your WordPress site also uses IP detection or geolocation features, make sure your Cloudflare settings pass the correct headers through.

Fix 8: Enable WordPress Debug Mode

If you’ve tried multiple fixes and still can’t figure out the cause, WordPress debug mode can reveal the underlying error.

Open wp-config.php via FTP or File Manager, and add these lines before the /* That's all, stop editing! */ comment:

// Enable debugging
define( 'WP_DEBUG', true );

// Log errors to /wp-content/debug.log
define( 'WP_DEBUG_LOG', true );

// Hide errors from visitors
define( 'WP_DEBUG_DISPLAY', false );

Now try loading your site. Even if it still downloads a file, WordPress will log the actual error to /wp-content/debug.log. Download that file and look for PHP fatal errors, missing module warnings, or file permission denials.

Common errors you might find:

• PHP Fatal error: Uncaught Error: Call to undefined function — a plugin requires a PHP extension that’s not installed
• PHP Warning: require_once(...): Failed to open stream — a file is missing or permissions block access
• mod_rewrite module is not loaded — Apache’s rewrite module is disabled

Quick Note: Always disable debug mode after troubleshooting by setting WP_DEBUG back to false. Leaving it enabled on a production site can expose sensitive error details and slow down performance.

How to Prevent This From Happening Again

After you’ve fixed the immediate issue, take these steps to make sure it doesn’t come back:

• Keep PHP updated — WordPress recommends PHP 8.1 or higher as of 2026. Set a calendar reminder to check your PHP version quarterly in cPanel’s MultiPHP Manager
• Back up .htaccess before changes — download a copy before installing new plugins, updating WordPress, or switching themes
• Use a staging environment — test plugin updates and PHP version changes on a staging site before applying to production
• Monitor your site — use an uptime monitor (UptimeRobot, Jetpack) that pings your site every 5 minutes. If your site starts returning a file download instead of HTML, you’ll know instantly
• Install a security plugin — Wordfence or Sucuri can detect .htaccess modifications and malware injections in real-time

If your WordPress site isn’t loading at all, check out our full troubleshooting guide for that scenario as well — the causes overlap but the debugging approach is slightly different.

Frequently Asked Questions

Summing Up!

The “WordPress download file instead of opening in browser” error is almost always a server-side configuration issue — not a WordPress bug. In my experience, 80% of cases are solved by either fixing the PHP handler in cPanel (Fix 1) or resetting the .htaccess file (Fix 2). The remaining 20% split between cache plugin conflicts, malware, and CDN settings.

Start with Fix 1 and work your way down. If nothing works after trying all eight fixes, contact your hosting provider’s support team — the issue may be on their end (server-level PHP configuration that you can’t access). And if you’re already thinking about switching hosts, that’s a conversation worth having if this keeps recurring.

Have you dealt with this error before? Which fix worked for you? Drop a comment below — I read every one and respond personally. And if you’re working on setting up your WordPress site’s meta tags or other configuration, make sure your server foundation is solid first!