iFastHostingHow to debug a blank white page
Nothing on the page at all, not even an error — here is how to make the failure describe itself instead of hiding.
A blank white page — no error, no styling, nothing but an empty browser tab — almost always means a PHP script failed fatally partway through running, and whatever would normally have described the failure is switched off. The failure is real. The silence is a setting, not a symptom of anything worse than the underlying error itself.
This is a display problem in the truest sense: the script stopped before it finished generating the page. It says nothing about whether your files or database are intact, and in the large majority of cases they are completely unaffected.
Make the error describe itself first
Everything else in this guide is much faster once you can actually see what failed. Turn on error display temporarily so PHP prints the real message instead of nothing at all.
For a plain PHP site, add these lines at the very top of the file being loaded — usually index.php:
ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);For WordPress, add these lines to wp-config.php, above the line reading "That's all, stop editing":
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', true );Reload the page. Where there was nothing, you should now see a message naming the exact file, line, and type of error — which turns the rest of this from guesswork into a direct fix.
Displayed errors on a live site expose file paths, and sometimes database details, to anyone who happens to trigger the same failure. Set display_errors back to 0, and switch WP_DEBUG_DISPLAY back to false, the moment you've read what you needed. Leaving WP_DEBUG_LOG on is safe and useful — it writes to a private log file rather than the screen.
The causes, in the order worth checking
1. A plugin or add-on has a fatal error
The single most common cause on any CMS. A plugin update, a compatibility issue with a new PHP version, or two plugins conflicting with each other can all produce a fatal error that halts the page before anything renders. With the error now visible from the step above, it will typically name the exact plugin file responsible.
If you can't get into the admin area to deactivate anything, rename the plugins folder directly in the file manager — for WordPress, renaming wp-content/plugins to something like plugins-off deactivates every plugin at once. Rename it back afterwards to reactivate them one at a time and find the specific culprit.
2. The active theme has a fatal error
A theme update or a manually edited theme file — commonly functions.php — can fail in exactly the same way as a plugin. If disabling plugins doesn't clear it, switching to a default theme temporarily isolates whether the theme itself is responsible.
3. The PHP memory limit has been exhausted
Running out of available memory partway through generating a page is one of the more common reasons nothing gets displayed at all, because the failure can occur before any output has been sent. See fixing "allowed memory size exhausted" for the specific fix, which is to raise the limit as a first step and identify what is consuming it as the real one.
4. A recently edited file has a syntax error
A missing semicolon or an unclosed bracket in a manually edited file stops PHP from running that file at all, which produces a blank page identically to a runtime fatal error. See fixing a PHP parse error for how to read the file and line number from the now-visible error message.
5. A caching layer is serving a broken cached copy
Less common, but worth ruling out on sites using aggressive page caching: if the underlying error was introduced, then a broken version of the page was cached before the error was fixed, visitors can keep seeing the blank cached copy after the actual problem is resolved. Clearing the site's cache confirms or rules this out quickly.
If turning on error display shows nothing either
An empty result even with display switched on points at a failure outside PHP entirely — most often a server-level issue such as permissions or a broken .htaccess stopping the request before PHP is even invoked. In that case, the error log section of your control panel is more likely to hold the answer than anything visible in the browser.
If you've reached this point without an answer, send us the URL, the time it started, and anything you changed just before — that combination is usually enough for support to identify it quickly from the server side.
Frequently asked questions
Why is there no error message at all, not even a generic one?
Because a fatal PHP error stops execution at the exact point it happens, and if that point is before the page has written anything to the browser, nothing is left to display — and if error display is switched off, as it should be on a live site, PHP does not put anything on screen in its place either. The result is silence rather than a message.
Is this different from a 500 error?
They frequently share the same cause, but not always the same presentation. A 500 is the server explicitly returning an error status with a page describing that something went wrong. A blank white page can occur even when the server returns a normal 200 status, because the failure happens inside the application after headers were already sent successfully — the connection succeeded, the content simply never arrived.
Related reading
The least informative error on the web. The real message is always in a log — here is how to find it and what it usually says.
How to fix "allowed memory size exhausted"PHP hit its memory ceiling and stopped rather than risk taking the whole server down with it — here is what to do about it.
How to fix a PHP parse or syntax errorPHP could not even read the file, let alone run it — here is how to use the exact line it names to find the real mistake.
How to fix "Error establishing a database connection"A blank page with one line of text, and five possible causes. Here is how to tell which one you have, in the order worth checking.