How to Fix WordPress Header Image Not Showing — Complete Guide
The WordPress header image not showing is a display issue caused by caching, theme…
How to Fix WordPress Cannot Modify Header Information Error
- Error
WordPress Cannot Modify Header Information Headers Already Sent- Affects
- WordPress Errors
What Is This Error?
When WordPress throws “Cannot Modify Header Information — Headers Already Sent,” it means PHP tried to send an HTTP header after content had already been output to the browser. HTTP headers must travel first — once even a single character goes out, it is too late to send them.
The error message usually includes a hint like: output started at /wp-content/plugins/some-plugin/file.php:1. That file path and line number is your starting point — it tells you exactly where the premature output originated.
This won’t take your entire site offline, but it breaks redirects, logins, and cookie-dependent features. If you suddenly can’t log in to wp-admin or pages stop redirecting correctly, this error is almost certainly the culprit.
Why Does This Happen?
- Whitespace before <?php: PHP files must begin with <?php on line 1. A blank line or space before it is treated as output and sent to the browser immediately.
- A BOM (Byte Order Mark) embedded in the file: Some text editors silently add an invisible UTF-8 BOM character at the very start of files. PHP outputs it before executing a single line of code.
- A closing ?> tag with trailing whitespace: PHP files do not require a closing ?> tag. If one exists and there are spaces or blank lines after it, that content is sent as output before any headers.
- An echo, print, or HTML block before a header() call: Any content printed or rendered before wp_redirect(), setcookie(), or header() will immediately trigger this error.
- A recently installed plugin or theme with encoding issues: A corrupted or improperly encoded file can produce invisible characters before the opening PHP tag, causing output before headers are sent.
How to Fix It — Step by Step
-
Read the full error message. Look for the path shown after “output started at” — for example,
/wp-content/themes/mytheme/functions.php:45. This gives you the exact file and line number. Open that file before doing anything else.You should see: A complete file path and line number that pinpoints where the unwanted output begins.
-
Check for whitespace before <?php. Open the file in a plain-text editor such as VS Code, Notepad++, or Sublime Text. The very first characters in the file must be
<?phpwith absolutely nothing before them — no spaces, no blank lines, no invisible characters.<?php // Your code starts here — nothing above this lineYou should see: The file opens directly with <?php on line 1, no preceding content of any kind.
-
Remove any closing ?> tags and trailing whitespace. WordPress PHP files — including functions.php and all plugin files — do not need a closing
?>tag. Delete it along with any blank lines or spaces that follow it at the bottom of the file.You should see: The file ends cleanly with PHP code and no closing tag or trailing empty lines.
-
Re-save the file without BOM. In Notepad++, go to Encoding → Convert to UTF-8 (without BOM) and save. In VS Code, click the encoding label in the bottom-right status bar, select “Save with Encoding,” then choose UTF-8. Upload the corrected file back to your server via FTP.
You should see: The error disappears and the broken WordPress feature — login, redirect, or cookie — works normally again.
-
Deactivate plugins one by one if the flagged file belongs to a plugin you did not write. If you are locked out of wp-admin, use FTP or your hosting file manager to rename the plugins folder from
/wp-content/plugins/to/wp-content/plugins_disabled/. Log in, then rename it back and reactivate plugins one at a time to identify the offender.You should see: After disabling the problematic plugin, the error stops appearing completely.
Common Mistakes When Fixing This
- Editing a nearby file instead of the exact one: Beginners sometimes open a file in the same folder as the one named in the error. Always use the precise path from the error message — no guessing.
- Treating ob_start() as a permanent solution: Adding output buffering suppresses the warning but leaves the broken code in place. Use it only as a short-term diagnostic workaround while you locate and remove the actual premature output.
- Saving the file with the wrong encoding: Resaving a PHP file as UTF-16 or ANSI instead of UTF-8 can introduce new invisible characters. Always explicitly select UTF-8 without BOM when saving.
- Only inspecting the top of the file: Most people check for whitespace at the beginning but forget to look at the bottom. Trailing whitespace after a closing
?>tag is just as guilty — check both ends of every flagged file.
Get free WordPress & AI tips
Join 500+ readers. No spam, unsubscribe anytime.
Frequently Asked Questions
Can this error come from a WordPress core file?
It’s extremely unlikely. WordPress core is rigorously maintained. If the error path points to a core file, your installation may be corrupted. Try reinstalling WordPress from Dashboard → Updates → Re-install now. That replaces core files without touching your content or settings.
I’m completely locked out of wp-admin because of this — what do I do?
Connect via FTP or your hosting control panel’s file manager. Rename the plugins folder from /wp-content/plugins/ to something like /wp-content/plugins_off/. This bulk-deactivates every plugin. Once you can log in again, rename the folder back and reactivate plugins one at a time until the error reappears — that’s your culprit.
Why did this error only start after I installed a new plugin?
The new plugin most likely contains a PHP file with a BOM, trailing whitespace after a closing tag, or an echo statement that fires during WordPress initialization. Deactivate it to confirm, then report the issue to the plugin author with the full error message so they can push a fix.
Is it ever safe to use ob_start() as the fix?
No — not as a final solution. Output buffering delays when content is sent, which can hide the warning, but the root cause stays in your codebase. Use it temporarily while debugging if you need the site functional, but always go back and fix the actual file. Leaving ob_start() in place is technical debt that can cause harder-to-diagnose issues later.
