Guide Errors & Troubleshooting

Why your browser is showing raw PHP code

Your page never rendered because the server handed out the raw source code instead of running it — here is why that happens.

iFastHosting Support Team Updated 26 August 2026 6 min read Intermediate

Instead of a rendered page, the browser shows the literal contents of a PHP file — text starting with <?php, followed by the actual code, exactly as it would look opened in a text editor. This means the server handed the file to the browser as plain text rather than passing it to the PHP interpreter to be run first. The browser is doing exactly what it's told; it was simply given source code instead of a finished page.

Treat any exposed credentials as compromised

If the file involved is one that normally contains database details or API keys — wp-config.php being the obvious example — anyone who loaded that page while it was exposed could read them in plain text. Once the underlying cause is fixed, change the affected passwords and keys rather than assuming a quick fix is the end of it.

The causes, in the order worth checking

1. The file has the wrong extension

The server decides whether to run a file as PHP based on its file extension, typically .php. A file saved or uploaded with the wrong extension — .html, .txt, or no extension at all — is served as-is, with its raw contents sent directly to the browser rather than executed first. Check the exact filename in your file manager; a rename to the correct extension usually resolves this immediately.

2. A handler directive in .htaccess has been changed

Configuration such as this, if present in .htaccess, explicitly tells the server to stop treating .php files as executable and serve them as plain text instead:

RemoveHandler .php
RemoveType .php

This is sometimes left behind after testing something unrelated, or copied from an unrelated guide without fully understanding what it does. Search .htaccess for any line containing RemoveHandler, RemoveType, or an AddType/SetHandler line that looks unusual, and remove or comment out anything that doesn't belong.

3. The PHP handler for the domain is misconfigured

Less common on managed hosting, but possible after a migration between servers or a change to how a subdomain is set up: the domain or folder may not be correctly linked to a PHP handler at all. Check the PHP version setting for the site in your control panel — if it shows as disabled, or the domain doesn't appear correctly configured there, that's the direct cause rather than anything in .htaccess.

4. A cached copy from before PHP was working is being served

If a CDN or caching layer cached the file's raw content during a period when execution genuinely wasn't working — during a migration, for instance — it can continue serving that broken cached copy even after the underlying issue on the server is fixed. Purge the cache for the specific file and reload to rule this out.

5. The file was accessed through a path that bypasses PHP entirely

Some hosting configurations serve certain folders — commonly ones intended for static assets like images or downloads — without passing requests through the PHP interpreter at all, on the reasoning that nothing in them should ever need to run as code. If a PHP file was placed inside one of those folders by mistake, it will always be served as raw text there regardless of anything else being correctly configured, and the fix is moving it to a location the server treats as executable.

This is different from a parse error

A parse error stops the file from running and typically results in a blank page or an error message, not the literal source code appearing. Seeing raw code means the file was never handed to PHP to attempt running in the first place — an earlier, different point of failure.

Confirming PHP itself is working

Create a simple test file named phptest.php containing only <?php phpinfo(); ?> and place it in the same folder as the affected file. If loading it shows a properly rendered PHP information page rather than the raw text, PHP is working correctly in that location and the problem is specific to the original file — its name, its extension, or a rule targeting it specifically.

Delete the test file immediately afterwards

phpinfo() reveals detailed information about the server's configuration that shouldn't be left publicly accessible. Remove it as soon as you have your answer.

If PHP itself isn't executing anywhere on the site

Note whether this affects every file or just one, and mention the exact file extension and its location. That's usually enough for support to check the PHP handler configuration for the domain directly and confirm whether it's a file-level or account-level cause.

Frequently asked questions

Has this exposed anything sensitive about my site?

Potentially, yes, if the file that displayed as raw text contains database credentials, API keys, or other configuration — which files like wp-config.php do. Treat this as a reason to rotate any credentials visible in the exposed file once it's fixed, not just as a cosmetic glitch to correct and forget.

Why does this happen to only one file and not the whole site?

Because whatever is preventing execution is usually specific to a file extension, a particular folder's configuration, or one file that was uploaded or renamed incorrectly, rather than a fault affecting PHP across the entire account. If every single page shows raw code, that points at something broader, such as PHP being disabled for the domain entirely.