How to Fix Headers Already Sent WordPress Errors
Table of Contents
That warning looks small, but it can break logins, redirects, and parts of your admin area fast. When I see the classic headers already sent WordPress error, I do not panic; instead, I immediately read the file path provided in the message. Identifying the source of this PHP warning is the first step toward a permanent resolution.
Most of the time, the cause is tiny. A blank line, an accidental character, or a file saved with the wrong encoding started output too early. It is very common to find these stray spaces or characters at the start or end of your wp-config.php file, which is a frequent location for this type of output error. Once I locate that first bit of premature output, the fix is usually quite simple.
Key Takeaways
- Locate the source: The “output started at” portion of the error message identifies the exact file and line causing the problem, which is almost never a core WordPress file.
- Watch for hidden characters: The most common causes are stray spaces, blank lines before opening PHP tags, or files saved with an incorrect encoding like BOM (Byte Order Mark).
- Back up first: Always secure a copy of your files or use a staging environment before editing code, as minor mistakes can easily lead to a broken site or a white screen.
- Avoid quick patches: Do not use output buffering (
ob_start) to simply hide the warning; always resolve the root cause by removing the accidental output in the source file.
What this WordPress warning is really saying
In plain English, the server is trying to send HTTP headers to your browser after the page content has already started loading. When the server reaches this state, you will encounter the headers already sent error. These headers are essential, as they handle critical tasks like setting cookies, managing redirects, and maintaining login sessions.
I think of headers like the outside of an envelope. You must address and stamp it first. If you have already stuffed the letter into the envelope and started sealing it, it is too late to change the outside cleanly.
A common version of the Cannot modify header information error looks like this:
Warning: Cannot modify header information - headers already sent by (output started at /public_html/wp-config.php:1)... output started at /wp-content/themes/your-theme/functions.php:12... output started at /wp-content/plugins/plugin-name/plugin.php:3
The part I care about most is “output started at”. That tells me where the problem originated. The second file mentioned in the message is often where WordPress finally noticed the conflict, not where it was caused.
Here is the quick read I use:
| Part of the warning | What I focus on |
|---|---|
output started at ... | The file and line that began sending output |
in /wp-includes/pluggable.php | Where WordPress later tried to send a header |
line 1435 | Helpful context, but usually not the root cause |
If the message ends in a file within wp-includes, such as pluggable.php, I do not edit that file first.
That mistake wastes a lot of time. WordPress core files found in wp-includes are usually innocent bystanders in these scenarios, as they are simply reacting to unauthorized output triggered elsewhere.
Back up first, then work on the copy
Before I edit any files, I always ensure I have a reliable way to restore from backup if something goes wrong. If I am working on a live site, I download the original file to my computer first. Having that clean copy on hand gives me a safety net if I accidentally make the situation worse.
If my host offers a staging environment, I use it. This error is often quick to fix, but quick fixes are exactly where people create bigger problems. A staging copy lets me test changes without taking down the real site.
When the dashboard still loads, I also like to enable WP_DEBUG. Configuring this setting to write errors to a debug.log file is the best way to track the exact location where output started. That is much more professional than dumping cryptic warnings in front of your visitors.
If I cannot get into WordPress at all, I switch to an FTP client or the host built-in File Manager. Tools like FileZilla or Cyberduck are perfectly fine for this task. The main priority is having direct access to your wp-config.php file, your theme files, and your plugins folder so you can resolve the issue manually.
The fastest way I fix headers already sent in WordPress
When I perform troubleshooting steps for this error, I keep it methodical. Guessing does not help, but the file path certainly does.
- Open the exact file named after output started at. If the message points to wp-config.php:1, I open that file. If it points to a specific line in functions.php, I open that theme file first.
- Go to the line number, then check above it. The bad output is not always on that exact line. It can be a blank line, stray whitespace, or an invisible character just before it.
- Look for whitespace outside of PHP tags. A classic problem is a space or blank line before the opening PHP tag. Another common issue is extra space after a closing PHP tag.
- Remove accidental output. I scan for debug code like echo statements, print statements, or var_dump functions. I also look for stray HTML or comments placed outside of PHP tags, as any accidental code execution here will trigger the error.
- Save the file as UTF-8 without BOM. This is often overlooked. A Byte Order Mark is invisible in many editors, but PHP treats it like output. If the warning references line 1 of your file, re-saving it in a proper code editor often clears the issue instantly.
I also watch for common habits, such as copying snippets from a website and pasting them into functions.php without verifying the opening and closing PHP tags. If a snippet includes an opening tag and I paste it into a file that is already open, I can trigger the error immediately.
For pure PHP files, I often remove the closing PHP tag entirely if it is not strictly necessary. This is standard practice in WordPress because it helps prevent trailing whitespace problems. If you are currently using a basic editor like Notepad, I recommend upgrading to VS Code, Sublime Text, or Notepad++ to make encoding and line numbers much easier to spot.
Finally, remember that you should never edit WordPress core files to fix the warning. If the error mentions a file in wp-includes, such as pluggable.php, that is simply where WordPress attempted to execute a function like wp_redirect, set a cookie, or start a session after output had already begun. The root cause is almost always an external file, not the core files themselves.
When a plugin or theme is the real culprit
A lot of these warnings show up right after a plugin or theme update. If the path points into /wp-content/plugins/ or /wp-content/themes/, I focus my troubleshooting steps there and nowhere else.
If I can still access the wp-admin area, I deactivate the plugin first. When I cannot access the wp-admin dashboard due to the error, I go in through SFTP and rename the plugin folder. WordPress will treat it as deactivated on the next load. If a simple folder rename resolves the error but the site functionality remains broken, you might need to reinstall plugin files from a fresh download to ensure no corrupt code remains.
When I do not know which plugin caused the issue, I rename the entire plugins folder to something like plugins-disabled. If the site comes back, I rename it back to plugins and disable one individual plugin folder at a time until the warning returns.
Themes work the same way. If the error points to the active theme, I rename that theme folder and let WordPress fall back to a default theme if one is installed.
I have also seen this warning show up only inside the dashboard, which can be extra confusing. This wp-admin-only case on WordPress Stack Exchange is a good example of how odd plugin-related cases can look.
If a bad edit turns the warning into a blank screen, I switch gears and use fixing the WordPress white screen of death. The recovery steps overlap a lot, especially when a plugin or theme is involved.
A few traps that make this error stick around
The biggest trap is treating the symptom instead of the cause. You will sometimes see developers suggest using output buffering with ob_start to hide the warning. While using ob_start can temporarily clear the Cannot modify header information message, I treat this as a quick patch rather than a permanent fix.
If I have not removed the actual early output, the underlying problem remains. The error is simply being suppressed rather than resolved.
The Stack Overflow discussion on output buffering is useful for understanding how people attempt to bypass this warning, but I still prefer fixing the source file directly.
Another trap is editing the wrong file because the technical warning looks intimidating. I ignore the final file path mentioned in the error message until I have thoroughly checked the first one. That simple habit saves me more time than any fancy debugging trick.
If you want another plain-English breakdown of how the Cannot modify header information error is structured, Kinsta has a helpful look at the message format. It is a handy resource when you are staring at a long file path and wondering which part of the code actually matters.
Frequently Asked Questions
Why do I see this error after installing a new plugin?
The error often occurs because the plugin has an improperly formatted PHP file, such as a space before the opening tag or an extra line at the end of the script. Since the plugin is new, check that specific plugin directory for files with accidental whitespace or incorrect encoding.
Can I fix this error by editing core files like pluggable.php?
You should never edit WordPress core files like wp-includes/pluggable.php to resolve this warning. These files are simply reporting that a header cannot be sent because something else already output content earlier; editing them will not fix the underlying cause.
What is the safest way to find the file causing the error if I am locked out?
If you cannot access your WordPress dashboard, use an FTP client or your host’s File Manager to check the file path identified in the error message. If the issue is a plugin or theme, you can rename the corresponding folder via FTP to temporarily disable it and restore site access.
Conclusion
When I fix this error, I do not treat it like a mystery. I treat it like a breadcrumb trail: read the first file path, back up the file, remove the early output, and test again.
Most headers already sent problems come from tiny edits rather than giant failures. By following these troubleshooting steps carefully, you can resolve the PHP warning without causing lasting damage to your site. Once you remember that the issue is usually just a bit of stray whitespace, the error stops feeling dramatic and starts feeling entirely fixable.