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:

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

(E_ALL);
(, )

 ;

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. is never executed.

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.

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.

// 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

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.