You’ll see this error as a PHP warning that reads Warning: Cannot modify header information – headers already sent by (output started at /path/to/file.php:line). It means something in your code is sending output to the browser before WordPress tries to set HTTP headers — cookies, redirects, or content-type declarations. The right way to fix this: find the file and line number in the error message, because PHP is telling you exactly where the problem is.

What Causes Warning: Cannot Modify Header Information?

Extra whitespace or blank lines before <?php — The most common cause. A single space or blank line before the opening PHP tag in wp-config.php, a plugin file, or your theme’s functions.php sends output before headers.
BOM (Byte Order Mark) in PHP files — Some text editors save files with an invisible UTF-8 BOM character at position 0. PHP treats this as output.
A plugin or theme echoing output too early — A poorly coded plugin running echo or print during init or plugins_loaded before headers are sent.
Error messages or notices displayed before headers — If WP_DEBUG_DISPLAY is on in production, PHP warnings from other issues can trigger this cascading header error.
Closing ?> tag followed by whitespace — Any whitespace or newline after a closing PHP tag gets sent as output. This is why WordPress coding standards say to omit the closing ?> tag entirely.

How to Fix It

Step 1: Read the Error Message Carefully

The error tells you the exact file and line number. Look at this part:

output started at /home/yoursite/public_html/wp-config.php:1

That means wp-config.php, line 1, is sending premature output. Write down the file path and line number — that’s your target.

If you can’t see the error on screen, enable the debug log:

// Add to wp-config.php, BEFORE the "That's all, stop editing!" line
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Then check wp-content/debug.log via FTP or SSH for the full warning.

Step 2: Remove Whitespace and BOM from the Offending File

Connect via FTP/SFTP or SSH and open the file referenced in the error. If it’s wp-config.php (the most common culprit):

Open the file in a code editor — VS Code, Sublime Text, or Notepad++. Skip the built-in cPanel editor; it can introduce encoding issues.
Check for blank lines or spaces before the opening <?php on line 1. Delete them.
Check the very end of the file. Remove any closing ?> tag and any whitespace after it.
Save the file with UTF-8 encoding without BOM. In VS Code, click the encoding in the bottom status bar and select “Save with Encoding” → “UTF-8”.

<?php
// wp-config.php must start EXACTLY like this.
// No blank line above. No space before <?php.
// No closing ?> tag at the end of the file. Define( 'DB_NAME', 'your_database' );

If you’re comfortable with the command line, you can strip a BOM with sed:

cd ~/public_html
sed -i '1s/^\xEF\xBB\xBF//' wp-config.php

Step 3: Check for a Plugin or Theme Conflict

If the error points to a file inside wp-content/plugins/ or wp-content/themes/, the fix is different. Deactivate the offending plugin first:

wp plugin deactivate plugin-folder-name

Or deactivate all plugins to confirm it’s a plugin issue:

wp plugin deactivate --all

Then reactivate them one at a time to find the culprit:

wp plugin activate plugin-name

If a theme file is the problem, switch to a default theme temporarily:

wp theme activate twentytwentyfour

Once you’ve identified the offending plugin or theme, open its file at the line number from the error and apply the same whitespace/BOM fix from Step 2. If it’s a third-party plugin, report the bug to the developer and look for an update.

Step 4: Fix Output Buffering as a Temporary Workaround

If you’ve cleaned the files and the error persists — or you need the site working while you track down the root cause — output buffering can suppress it. Add this to the top of wp-config.php, immediately after <?php:

<?php
ob_start();

Skip this if you want headaches later — output buffering masks the problem without fixing it. Use it as a stopgap while you find the real cause, then remove it.

Step 5: Check.htaccess for PHP Output

Occasionally a malformed .htaccess file triggers early output. Rename it and let WordPress regenerate it:

cd ~/public_html
mv.htaccess.htaccess.backup

Then visit Settings → Permalinks in wp-admin and click Save Changes to regenerate a clean .htaccess file.

Prevention

Always use a proper code editor that saves files as UTF-8 without BOM. Configure VS Code or Sublime Text as your default — never edit PHP files in the WordPress theme editor or cPanel’s built-in editor.
Never add a closing ?> tag at the end of PHP-only files. WordPress coding standards explicitly forbid it, and for good reason — trailing whitespace after ?> is the single most common cause of this error.
Keep WP_DEBUG_DISPLAY set to false in production with WP_DEBUG_LOG set to true. This prevents PHP notices from becoming output that breaks headers, while still logging issues for you to review.
Audit plugin and theme files after manual edits. Anytime you paste code from a blog post or tutorial into functions.php, check for hidden characters. Copy-pasting from web pages frequently introduces invisible Unicode characters or BOM markers.

Last verified: April 2026

Symptoms