You’re staring at a white screen, your WordPress site just died, and the error message reads Cannot modify header information – headers already sent. It’s one of those PHP warnings that looks scarier than it actually is, but it will lock you out of wp-admin and break every redirect on your site until you deal with it. Let’s cut through the noise.
This error happens when PHP tries to send an HTTP header after output has already been flushed to the browser. Headers must go first. Always. The moment a single byte leaves your script — even a space, a BOM character, or a stray blank line before <?php — PHP decides the header phase is over and throws Cannot modify header information in WordPress.
Why WordPress Throws This Error and Not Your Theme
WordPress core functions like wp_redirect(), setcookie(), and wp_set_auth_cookie() all rely on raw PHP headers. When a plugin or theme prints something before those functions run, the redirect or cookie fails silently and WordPress logs the warning.
The usual suspects in 2026 are still the classics: a plugin file with a trailing space after the closing ?> tag, a corrupted functions.php with hidden whitespace, or a caching plugin that starts output buffering too late in the load order.
If you’re seeing this after updating a plugin, that plugin is almost certainly the cause. Deactivate it via FTP or WP-CLI and the error disappears instantly.
How to Find the Exact File Sending Output Too Early
The error message itself gives you the answer — read the part after output started at. It points to a file path and line number. That’s your culprit, not the file where the warning is displayed.
Common locations for a WordPress headers already sent error include:
- /wp-config.php with a space before <?php or after the final line
- A plugin file with a UTF-8 BOM saved by an old text editor
- functions.php with an accidental echo or HTML block before a redirect
- A mu-plugin loading before the theme that prints debug output
Open that file in a code editor that shows invisible characters. Delete anything before the opening PHP tag and remove the closing tag entirely if it’s at the end of the file — PHP doesn’t need it and it’s a magnet for trailing whitespace.
Output Buffering: The Real Fix, Not a Hack
You’ll read a lot of advice telling you to slap ob_start() at the top of functions.php. It works, but it’s a band-aid. The proper approach when dealing with cannot modify header information errors in WordPress is to fix the source, not mask the symptom.
That said, there’s a legitimate case for output buffering: legacy plugins you can’t modify. In that scenario, add this to your wp-config.php before wp-settings.php is required:
define(‘WP_USE_THEMES’, true);
ob_start();
Keep in mind this delays output, it doesn’t eliminate it. If the plugin echoes content you didn’t expect, that content still appears — just later. So you’ve traded a broken redirect for a visible garbage string. Not ideal.
Blank Lines, BOM Characters, and Other Silent Killers
A single newline after ?> at the end of a PHP file is enough to trigger the WordPress cannot modify header information warning. It’s brutal, but that’s how PHP works.
Check these specific things when debugging the error:
- Save all PHP files as UTF-8 without BOM in your editor
- Remove closing ?> tags from all custom PHP files
- Verify no whitespace exists before <?php on line 1
- Disable plugins one by one to isolate the offender
- Switch to a default theme (Twenty Twenty-Five) to rule out your theme
Nine times out of ten, disabling plugins in bulk and reactivating them in batches finds the guilty party in under five minutes.
JavaScript and Meta Refresh as a Redirect Workaround
When you genuinely cannot fix the PHP side — say you’re on shared hosting with locked files — you can bypass headers entirely. JavaScript redirects and meta refresh tags don’t touch HTTP headers at all.
Client-side redirect example:
<script>window.location.href = «https://yoursite.com/thank-you/»;</script>
Meta refresh alternative:
<meta http-equiv=»refresh» content=»0;url=https://yoursite.com/thank-you/»>
Both work, but hear me out: this is a downgrade. You lose HTTP status codes (no more 301s), SEO signals get muddier, and if JavaScript is disabled or blocked by a browser extension, your user sits on a dead page. Use it as a last resort, not a solution.
When the Error Isn’t Your Fault at All
Sometimes the cannot modify header information error comes from your hosting environment. A misconfigured PHP-FPM pool, an aggressive mod_security rule, or a server-level prepend file can inject output before WordPress even boots.
Test this by creating a bare test.php with nothing but a redirect header. If it fails, the problem lives on the server, not in your installation. At that point, contact your host with the exact error path — they can check php.ini for auto_prepend_file settings that are polluting the output stream.
One more thing: if you run a staging environment, always test plugin updates there first. The WordPress cannot modify header information warning after an update is almost always a plugin regression, and rolling back is faster than debugging.
