How to debug a blank white page in PHP

A completely blank white page from PHP means something failed badly enough to stop execution, and the server's configuration happens to be hiding the error rather than showing it — it very rarely means nothing happened at all. The fix is always the same first move: make the error visible, then read what it actually says.

Step 1: turn errors on

If the page fails before your own code even runs — a parse error in the file itself, for instance — adding lines inside the script will not help, because PHP never reaches them. Set this at the server level instead, through the PHP settings area of your control panel or a user-level php.ini:

display_errors = On
error_reporting = E_ALL

If the page does start running and only fails partway through, adding the same settings at the top of the specific script works just as well and is quicker for a single file:

<?php
ini_set('display_errors', '1');
error_reporting(E_ALL);

Our fuller guide to turning PHP error display on covers both routes in more detail, including the reminder to turn this back off once you have your answer — a page happily printing file paths and code detail to every visitor is not something to leave running.

Step 2: reload and read what appears

With errors visible, reload the page. You should now see the error type, a message, and the file and line number where it happened. That is almost always enough to know where to look:

• Parse error — a syntax mistake in the named file, often a missing semicolon, an unclosed bracket, or a stray character left over from editing.
• Fatal error: Uncaught Error — commonly a call to a function or method that does not exist, frequently because a plugin or package has not been updated for the PHP version currently running.
• Fatal error: Allowed memory size exhausted — see increasing the PHP memory limit.
• Maximum execution time exceeded — see increasing max execution time.

If even that shows nothing

Occasionally a failure happens somewhere that display_errors genuinely cannot reach — a crash at a level below PHP's own error handling. In that case, go straight to the log rather than the browser:

tail -50 ~/logs/php_errors.log

Reading a PHP error log covers where this file typically lives and how to interpret an entry once you have it in front of you. The log records fatal errors regardless of what display_errors is set to, which makes it the more reliable source once display_errors alone has not turned anything up.

A quick way to narrow down which file is responsible

On a site built from many included files — a CMS with plugins, a framework with a long bootstrap sequence — the file named in the error is not always the one that actually needs fixing; it may simply be the file that was running when something included earlier caused the problem. A short, deliberate process narrows it down faster than guessing:

1. Note what changed most recently

   A new plugin, a manual code edit, an update applied just before the white page appeared — this is disproportionately likely to be the cause.

2. Temporarily disable the most recent change

   Deactivate the newest plugin, or revert the most recent edit, and reload. If the page comes back, you have found the culprit without needing to read a single line of the error.

3. If nothing was changed recently, check hosting-side factors

   A PHP version change applied by an automatic update, a limit reached for the first time as traffic or data has grown, or a dependency that quietly reached its own end of support are all worth checking against the timing of when the page started failing.

Once you can see the actual error, the fix is almost always specific and quick — a version mismatch, a missing extension, a limit that needs raising. The white page itself was never the problem, only the thing standing in the way of seeing what was. Get into the habit of checking the log first the next time a page goes blank, rather than reaching for display_errors by default — it saves the extra step of remembering to switch the setting back off afterwards.