Fix “Cannot Modify Header Information” in PHP (Fast Guide)
Ever tried to redirect a user or set a cookie in PHP, and suddenly “Cannot modify header information” smacks you in the face?
It usually shows up when everything seems correct, which is what makes it so irritating.
This error happens when PHP sends any kind of output before calling header(). Most of the time the culprit is something tiny—extra whitespace, an unexpected echo, or a noisy include file.
Below, I’ll break down why this error appears and what you should fix first.
Quick Summary
- The error means your script sent output before calling
header(). - Whitespace, BOM, echo/print, or HTML outside
<?php ?>tags usually cause it. - Fixes include removing accidental output, using output buffering, and checking include files.
Introduction
If you’ve worked with redirects, file downloads, or cookies in PHP, you already know how important header() is. It’s the thing that tells the browser what to do — redirect a user, change content type, control caching, all that stuff.
But there’s one strict rule with header(): it can’t run after PHP has sent any output.
And “output” in PHP isn’t just echo. It includes:
echo,print,var_dump()- Any HTML sitting outside
<?php ?> - A random space or newline before
<?phpor after?>
Once PHP sends even a tiny bit of output, it sends the headers along with it. After that, if your script tries to call header(), PHP throws the classic warning:
Warning: Cannot modify header information - headers already sent by (output started at /path/to/file.php:line)What makes this annoying is that the line number in the warning often points to the wrong place — sometimes the actual issue is hiding inside an included file. So you end up debugging lines that aren’t even guilty.
In this guide, I’ll break down why this error happens, where it usually hides, and the exact fixes that solve it without wasting your time.
Common Causes & Fixes
This error usually comes from small, annoying details in your code. Here’s a clear list of what triggers it and how to fix each one right away.
1. Whitespace Before <?php or After ?>
Cause:
A random space, newline, or even a BOM at the start or end of your PHP file sends output before PHP can modify headers.
Fix:
- Make sure the file starts exactly with
<?php— no spaces. - If your file ends with
?>, either remove it or ensure nothing comes after it. - Use an editor that highlights invisible characters (VS Code, PHPStorm, Sublime).
2. Output Before Header Calls (echo, print, HTML, etc.)
Cause:
Anything that prints to the browser before header() — even an empty string — will break headers.
Fix:
Move all header-related functions to the very top of your script:
Wrong:
<?php
echo "Hello!"; // Output sent here
header("Location: success.php"); // Error
exit;Correct:
<?php
session_start(); // At the top
header("Location: success.php");
exit; // Always exit after redirect3. HTML Appearing Before PHP Headers
Cause:
HTML, comments, or DOCTYPE above your PHP block sends output instantly.
Fix:
- Move your PHP header logic before any HTML.
- If needed, restructure the file so PHP handles the redirect first.
4. Debugging Functions (var_dump, print_r, etc.)
Cause:
Developers often forget to remove debugging outputs before redirecting or modifying headers.
Fix:
- Remove or comment them out.
- If you need debugging, output after all header logic or log to a file.
5. Errors Triggered Before Header Calls
Cause:
A PHP notice, warning, or fatal error outputs text to the browser before your header() runs.
Fix:
Temporarily enable full error reporting to spot the issue:
error_reporting(E_ALL);
ini_set('display_errors', 1);Put these at the top of your script, fix the underlying error, then remove them for production.
6. Included/Required Files Causing Output
Cause:
Your main script may be clean, but an included file might be the one sending output.
Fix:
- Check every included file for whitespace, BOM, echo statements, or HTML.
- Fix them the same way as your main file.
- Repeat for nested includes.
Test the Fix
Once you’ve applied the fixes, run through a quick sanity check:
- Clear your browser cache.
- Restart your local server (XAMPP, WAMP, Laragon, etc.).
- Reload the PHP file and watch for any remaining output.
- If you want to see what PHP is actually sending, use
headers_list():
<?php
header("Location: home.php");
print_r(headers_list()); // Shows all headers sent
exit;This helps confirm whether headers were sent earlier than expected.
Extra Tips
- Always call
exit()after a redirect to stop the script cleanly. - If you’re unsure about hidden output, wrapping your script with
ob_start()can save you from headaches. - Try not to mix HTML and PHP in the same file when working with redirects or cookies — it reduces risk of accidental output.
- During development, enable full error reporting to catch issues early:
Related Errors or Alternative Scenarios
“Headers already sent by…” with a file and line number
This message is more useful than it looks. It tells you where PHP first sent output. Open that file, jump to that line, and check for whitespace, HTML, or debug prints.
Setting a cookie after echosetcookie() works the same way as header(). If anything is echoed before it, the cookie won’t be sent.
session_start() throwing the same warningsession_start() also sends headers (Set-Cookie for the session ID). If you see this error here, you’ve got output happening before the session starts — same root cause, same fix.
FAQ
1. What does “Cannot modify header information” actually mean?
It means PHP already sent output, so it can’t send or modify HTTP headers anymore.
2. Does removing the closing ?> help?
Yes. PHP files that contain only PHP code should not include a closing tag — it prevents accidental whitespace.
3. Why does the error point to the wrong line?
Because the actual output often comes from an included file. PHP reports where output started, not where the header was called.
Conclusion
This error feels annoying the first few times, but it always comes down to the same rule: PHP can’t modify headers after output starts.
Keep header-related code at the top, avoid stray whitespace, and don’t leave debug prints lying around. Once you get used to checking these spots, this warning becomes a quick fix instead of a headache.
