How to Display PHP Errors in the Browser

By the end of this page, you will understand how PHP error reporting works, why some PHP errors appear as a blank page, and what to check when display_errors seems enabled but errors still do not show. You will also learn the difference between runtime errors and parse errors, where configuration can override your settings, and how developers usually debug this safely in real projects.

PHP error display depends on when the error happens and which configuration file or environment is controlling PHP.

The key idea is this:

• error_reporting(E_ALL); tells PHP which kinds of errors to report.
• ini_set('display_errors', '1'); tells PHP to display them.
• But these lines only run after PHP has already started executing the script.

That matters because parse errors happen before execution begins. If PHP cannot parse the file, it never reaches your error_reporting() or ini_set() calls.

This is why a script can show a blank page even though those lines are present.

Why this matters

In real development, seeing errors quickly helps you:

• fix syntax mistakes faster
• debug broken logic
• identify missing files, undefined variables, and failed function calls
• avoid wasting time on blank pages

At the same time, displaying raw errors in production is dangerous because error messages can reveal:

• file paths
• SQL details
• server configuration
• internal application structure

So the usual rule is:

• development: display errors
• production: log errors instead of showing them

Common reasons errors do not display

Even when you think PHP is configured correctly, one of these may still be true:

• You are editing the wrong php.ini file.
• Apache or PHP-FPM is using a different configuration than the one you changed.
• .htaccess, virtual host config, or server config overrides the setting.
• display_startup_errors is off, so startup-related issues stay hidden.
• The script has a parse error, so your ini_set() code never runs.
• Errors are being logged instead of displayed.
• Output is being handled by a framework or custom error handler.

Important distinction: parse errors vs runtime errors

A very common beginner mistake is assuming this code can show every error:

error_reporting(E_ALL);
ini_set('display_errors', '1');

It can show many runtime errors, warnings, and notices, but not syntax errors in the same file before PHP parses it successfully.

For parse errors, the display setting must already be active at the server or configuration level before the file is loaded.

Think of PHP like a speaker reading a script aloud.

1. First, the speaker checks whether the script is written correctly.
2. Only if the script is valid does the speaker start reading it.
3. Your error_reporting() and ini_set() lines are part of the script itself.

So if the script has a syntax mistake, PHP stops at step 1. It never gets to the lines that tell it to display errors.

Another way to think about it:

• php.ini settings are the house rules set before the game starts.
• ini_set() is changing rules during the game.
• A parse error means the game never even starts.

That is why server-level configuration is so important when debugging blank pages in PHP.

Core syntax

Enable error reporting in a PHP script:

error_reporting(E_ALL);
ini_set('display_errors', '1');

Useful related setting:

ini_set('display_startup_errors', '1');

Example: runtime error that can be displayed

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

include 'file-that-does-not-exist.php';

echo $undefinedVariable;

What this does

• include of a missing file usually triggers warnings.
• echo $undefinedVariable; triggers a notice or warning depending on PHP version.
• Because the file parses correctly, PHP reaches the error settings and can display these messages.

Example: parse error that these lines cannot catch

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

echo "Hello";

This file is missing a semicolon after ini_set(...).

PHP must parse the whole file before executing it. Because parsing fails, the script never reaches the error display lines.

Safer development configuration in php.ini

display_errors = On
display_startup_errors = On
error_reporting = E_ALL
log_errors = On

This setup is useful during development because:

• errors are shown in the browser
• errors are also written to logs

Check active settings with phpinfo()

Create a file like this:

<?php
phpinfo();

Then open it in the browser and check:

• Loaded Configuration File
• display_errors
• display_startup_errors
• error_reporting

This helps confirm whether you are editing the correct configuration file.

Consider this valid script:

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

echo $name;

Step by step

1. PHP reads the file.
2. The file has valid syntax, so parsing succeeds.
3. PHP executes error_reporting(E_ALL);.
4. PHP executes ini_set('display_errors', '1');.
5. PHP reaches echo $name;.
6. $name is undefined, so PHP raises an error message.
7. Because display is enabled, the message appears in the browser.

Now compare it with this file:

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

echo "Test";

What happens here

1. PHP reads the file.
2. PHP finds a missing semicolon after error_reporting(E_ALL).
3. Parsing fails.
4. Script execution never starts.
5. ini_set('display_errors', '1'); is never executed.
6. Whether you see the parse error now depends entirely on server-level PHP configuration.

That is the main reason blank pages happen with syntax errors.

Local development

When building a PHP app on your machine, displayed errors help you quickly fix:

• syntax mistakes
• undefined variables
• missing includes
• wrong function arguments

Debugging a staging server

On a test environment, developers may temporarily enable displayed errors to investigate a broken page, then disable them again afterward.

Logging production failures

In production, teams usually keep display_errors off and use logs instead:

• PHP error log
• Apache or Nginx error log
• application log files
• monitoring tools

Diagnosing blank pages

A blank page in PHP often means one of these:

• fatal error
• parse error
• startup error
• output buffering hides visible output

Knowing how error display works helps you narrow down the cause quickly.

CLI vs browser debugging

When running PHP from the command line, parse errors are often shown directly in the terminal even if browser output is blank. This is useful for testing a file quickly:

php test.php

In real projects, developers rarely rely only on placing ini_set() at the top of a file.

Common patterns

Environment-based configuration

Applications often use different settings for development and production:

<?php
if ($_ENV['APP_ENV'] === 'development') {
    error_reporting(E_ALL);
    ini_set('display_errors', '1');
} else {
    ini_set('display_errors', '0');
    ini_set('log_errors', '1');
}

Logging instead of displaying

In production, developers usually prefer:

• display_errors = Off
• log_errors = On

This prevents sensitive details from being exposed to users.

Guarding against silent failures

Developers check logs when a page is blank because blank output often means the error happened before normal rendering.

Framework integration

Frameworks may provide their own error pages and exception handlers. Even then, PHP's base error configuration still matters, especially for startup and parse issues.

Syntax checking before deployment

Teams often run a syntax check in scripts or CI pipelines:

php -l file.php

This catches parse errors before the code reaches a browser.

Practical checklist developers use

• Confirm the correct php.ini with phpinfo().
• Restart the right service: Apache, PHP-FPM, or both.
• Check server logs.
• Enable display_startup_errors in development.
• Use php -l for syntax checking.
• Verify no local config overrides are disabling display.

1. Expecting ini_set() to catch parse errors

Broken example:

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

Problem:

• The file itself has a syntax error.
• PHP never executes ini_set().

How to avoid it:

• Enable errors in php.ini for development.
• Run php -l yourfile.php to detect syntax issues.

2. Editing the wrong php.ini

Many systems have multiple PHP configurations, for example:

• CLI PHP
• Apache module PHP
• PHP-FPM

How to avoid it:

• Use phpinfo() in the browser.
• Check Loaded Configuration File.

3. Forgetting to restart the correct service

You may restart Apache, but your setup might actually use PHP-FPM.

How to avoid it:

• Restart the web server and PHP process manager if needed.

4. Confusing display_errors with log_errors

If display_errors is off but log_errors is on, the browser may stay blank while the real message goes into a log file.

How to avoid it:

• Check PHP error logs and web server logs.

5. Not enabling startup errors

Some failures happen before normal script execution.

How to avoid it:

Add in development:

ini_set('display_startup_errors', '1');

Or set it in php.ini.

6. Assuming blank page means no error exists

A blank page often means there is an error, but it is hidden.

How to avoid it:

• Check browser output
• check PHP logs
• check server logs
• run syntax linting

7. Using display errors in production

Broken practice:

display_errors = On

Problem:

• Users may see sensitive internal details.

Better approach:

display_errors = Off
log_errors = On

display_errors vs log_errors

Script-level config vs server-level config

// Show most runtime errors during development
error_reporting(E_ALL);
ini_set('display_errors', '1');
ini_set('display_startup_errors', '1');

; Development php.ini settings
display_errors = On
display_startup_errors = On
error_reporting = E_ALL
log_errors = On

<?php
phpinfo(); // Check which php.ini is actually loaded

php -l file.php   # Syntax check a PHP file

Rules to remember

• ini_set() only works after the script starts executing.
• Parse errors happen before execution.
• Blank page often means an error is hidden.
• phpinfo() helps confirm the active config.
• In production, prefer logging over displaying.

Quick troubleshooting checklist

1. Create a phpinfo() page.
2. Check Loaded Configuration File.
3. Verify display_errors, display_startup_errors, and error_reporting.
4. Restart Apache, Nginx, or PHP-FPM as needed.
5. Check PHP and web server logs.
6. Run php -l yourfile.php for syntax errors.
7. Make sure no .htaccess or local config overrides the settings.

Why does PHP show a blank page instead of an error?

A blank page usually means PHP hit a fatal, parse, or startup error, but error display is disabled or misconfigured.

Why doesn't ini_set('display_errors', 1) show syntax errors?

Because syntax errors happen before the script executes. PHP must parse the file first, so it never reaches that line.

How do I know which php.ini file my website is using?

Create a file with phpinfo(); and open it in the browser. Look for Loaded Configuration File.

Should I enable display_errors on a live website?

No. On production systems, keep display_errors off and use logging instead.

What setting should I use to see startup-related errors?

Enable display_startup_errors in development.

How can I check a PHP file for syntax errors quickly?

Use:

php -l yourfile.php

If errors still do not appear, where should I look next?

Check the PHP error log, Apache or Nginx error log, and confirm that no local server configuration is overriding your settings.

• PHP php.ini configuration — Related because error display usually depends on global PHP settings.
• PHP error reporting levels — Related because E_ALL controls which error types are reported.
• PHP parse errors — Related because syntax errors happen before script execution.
• PHP fatal errors — Related because fatal errors often cause blank pages.
• PHP logging — Related because production applications usually log errors instead of displaying them.
• phpinfo() — Related because it shows the active PHP configuration.
• PHP command line linting — Related because php -l helps detect syntax errors quickly.
• Apache and PHP-FPM configuration — Related because web server setup can override PHP error settings.