WordPress Downloading a File Instead of Opening in Browser? 8 Fixes (2026)

This is where I start, because it is usually the actual cause. When a host moves you from, say, PHP 7.4 to 8.2, any handler pointing at the old version breaks, since that version is gone.

In cPanel, open MultiPHP Manager. You will see each domain and the PHP version it currently uses.

1. Tick the affected domain.
2. From the PHP Version dropdown, pick a current, supported release. PHP 8.1 or newer is the safe choice today.
3. Click Apply.

Setting the version cleanly often regenerates the correct handler and the download stops on the spot. It is worth knowing that around a quarter of WordPress sites still run PHP older than 8.0, with PHP 7.4 alone sitting near 18 percent, so a lot of sites are one host upgrade away from exactly this problem.

No cPanel? On a managed host (Kinsta, WP Engine, SiteGround) the PHP version lives in the dashboard, or you ask support to set it.

.htaccess is the rules file Apache reads on every request. If it is corrupted or carries an old handler line, the server serves your pages as downloads.

Resetting it to the WordPress default is the single fix that clears this for the most people.

Connect with FTP or your host's File Manager and open .htaccess in your site root (the folder with wp-config.php). Turn on "show hidden files" if you do not see it.

1. Download a copy first. This is your undo button.
2. Open the file and delete everything inside.
3. Paste in the current default block, from the official WordPress server docs:

# BEGIN WordPress

RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

4. Save, then reload your site in a private window.

If the site loads, the old .htaccess was the culprit. You can rebuild a clean copy any time by going to Settings → Permalinks in the dashboard and clicking Save once, which WordPress uses to regenerate this file.

Sometimes the reset is not enough because a plugin keeps writing the bad line back, or it lives outside the WordPress block. Open .htaccess again and hunt for any line that names a PHP version directly:

# These are the troublemakers, delete or comment them out:
AddHandler application/x-httpd-php74 .php
AddHandler application/x-httpd-php5 .php
AddType application/x-httpd-php .php

Any handler that names a PHP version your server no longer runs will break execution. Delete those lines, or put a # in front of each to comment it out, then save.

On a modern cPanel server you do not need a manual handler at all, the panel generates the correct one. So in most cases the right move is to remove the line, not rewrite it. If it keeps reappearing after a reset, a plugin is writing it, which points you straight to the next fix.

Caching plugins write their own rules into .htaccess. WP Super Cache, W3 Total Cache, WP Fastest Cache and WP Rocket all do this, and if their rules reference a handler that has moved, the page comes down as a file.

If you can still reach the dashboard, deactivate the cache plugin, clear the cache, and reload.

Locked out of wp-admin too? Disable it over FTP instead. Rename the plugin's folder inside wp-content/plugins/:

# Rename to switch it off without deleting it
wp-content/plugins/w3-total-cache  →  wp-content/plugins/w3-total-cache.off

WordPress cannot find the plugin under the new name, so it deactivates it safely. Reload the site. If it comes back, that plugin was the cause, reset .htaccess once more (Fix 2) to clear any rules it left behind, then reinstall a fresh copy.

Wrong permissions can stop PHP files from being read and executed, which shows up as the same download behaviour. This one comes up most after a migration or a clumsy bulk chmod.

The values WordPress recommends, per its hardening guide:

Over SSH you can set them in two commands from your site root:

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

Then lock down the config file on its own:

chmod 440 wp-config.php

One firm rule: never set anything to 777. It means anyone can write to the file, and it is one of the first things attackers look for. If a tutorial tells you to chmod 777, close the tutorial.

If you reset .htaccess, it works for an hour, then the download is back, you are not chasing a config bug.

Something is rewriting the file, and that is almost always injected code.

This is not a rare edge case. Patchstack recorded 11,334 new WordPress vulnerabilities in 2025, up about 42 percent on the year before, and almost all of them sit in plugins and themes, not core.

Two checks I run:

1. Install Wordfence and run a full scan. Its free tier flags modified core files and suspicious code in .htaccess.
2. Verify core files over WP-CLI if you have SSH:

wp core verify-checksums

This downloads the official checksums for your version and compares them to your files. Any line it flags is a core file that has been changed, a strong sign of a hack.

If core is compromised, reinstall it cleanly from Dashboard → Updates → Reinstall, which overwrites core files without touching your content. A solid security plugin is one of the must-have WordPress plugins for exactly this reason.

If you run Cloudflare or another CDN, the edge sits between the visitor and your server, so a setting there can change what the browser receives even when your origin is fine. The tell: it happens on some pages, or it disappears when you bypass the cache.

The usual offender is Automatic Signed Exchanges (SXG). Site owners have reported on Cloudflare's own community forum that it can break rendering in Chrome. To rule it out:

1. In your Cloudflare dashboard, go to Speed → Optimization (or Caching) and turn Automatic Signed Exchanges off.
2. Go to Caching → Configuration and click Purge Everything.
3. Reload your site in a private window.

While you are there, check Page Rules and Transform Rules for anything that rewrites response headers or content type. Test with the CDN paused (Overview → Pause Cloudflare on Site) to confirm whether the edge or the origin is at fault.

If you are still here, stop guessing and make WordPress show its work. Edit wp-config.php and, just above the /* That's all, stop editing! */ line, add:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Reload the site, then read wp-content/debug.log. A fatal error naming a plugin or a missing PHP function tells you exactly where to look, far faster than trying fixes blind.

Turn debugging back off once you are done. Leaving WP_DEBUG on in production can leak paths and warnings to visitors.