Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsThe warning means PHP tried to send a redirect, cookie, session change, or other HTTP header after some output had already been sent. Start with the file and line identified after output started at; that earlier location is usually the cause, while the later location is where the header operation failed.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
Inspect that source file in a plain-text editor, remove any unintended output, save it as UTF-8 without BOM, and then verify that calls such as wp_redirect() run before templates, debug output, or other text. The procedure below shows how to trace the message without damaging WordPress core.
As an Amazon Associate I earn from qualifying purchases.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11What the warning actually means
PHP builds an HTTP response in two stages. It first sends a header block containing instructions for the browser, such as a redirect destination, a cookie, a cache rule, or a session change. It then sends the response body, which is the page markup or other visible output. Once the body has begun, the header block is already closed. PHP’s manual states: “You can’t add any more header lines using the header() function once the header block has already been sent.”
WordPress relies on this ordering for login flows, administration screens, form handlers, cookies, and redirects. A stray character can therefore break an operation that appears unrelated to the file that contains the mistake. The visible message is a symptom of the ordering problem, not proof that the file named at the end of the warning is damaged.
How to read the error message
A typical warning has two locations, for example:
Warning: Cannot modify header information - headers already sent by (output started at /path/wp-config.php:34) in /path/wp-login.php on line 42Read the locations from left to right:
| Part of the warning | What it tells you | What to do |
|---|---|---|
output started at /path/wp-config.php:34 |
The first output was produced at line 34 of wp-config.php. |
Investigate this file first, including the area before and after the reported line. |
in /path/wp-login.php on line 42 |
WordPress later attempted a header operation at line 42. | Use it to understand which action failed, but do not assume it is the source. |
If the message names an included plugin file, theme file, or must-use plugin as the output location, follow that path instead. The earliest location is the useful diagnostic clue; later locations are commonly victims of the same output.
Seven-step repair procedure
-
Copy the complete warning
Save the entire message, including both paths and line numbers. A partial copy can omit the only location that identifies the cause. If several warnings appear, record the first output location in each one and note which action triggered them, such as logging in, submitting a form, opening the dashboard, or following a redirect.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy. -
Open the source file as plain text
Use an editor that displays the file contents without applying rich-text formatting. Open the path shown after
output started atand jump to the reported line. Inspect nearby characters, then inspect the very beginning and very end of the file. The beginning and end matter because an invisible character outside the PHP code can be emitted before the interpreter reaches the code that sets headers. -
Check recent changes and included files
Make a short list of files changed immediately before the problem appeared. Include
wp-config.php, the active theme, ordinary plugins, must-use plugins, and PHP files loaded withincludeorrequire. If the warning points into a core file but a custom file was edited recently, examine the custom file first. Do not make broad edits to core while the source location remains unidentified. -
Remove unintended output
Delete stray spaces or blank lines outside PHP, accidental HTML, temporary messages, and debugging calls such as
echo,print_r(), orvar_dump()that execute before the header operation. Also remove any warning text generated by an earlier mistake; a PHP notice or warning is output just like ordinary text when it is displayed. -
Save without a UTF-8 BOM
Choose the editor’s UTF-8 encoding option that does not add a byte-order mark (BOM). A BOM is an invisible sequence at the start of a file, but PHP can interpret it as output. Reopen the file or use the editor’s encoding indicator to confirm that the file was saved in UTF-8 without BOM rather than merely assuming that the setting changed.
Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy. -
Replace an uncertain file safely
If the file is a WordPress core or configuration file and you cannot tell which changes are intentional, restore a known-good backup. If no trustworthy backup exists, obtain a fresh WordPress copy and replace only the damaged core file or files, preserving required configuration values in
wp-config.php. Keep a copy of the current file before replacement so that custom settings can be compared rather than lost. -
Review the failed header operation
Search the code path that failed for
wp_redirect(),header(), cookie calls, or session calls. These statements must execute before any response body is produced. Remove output that runs first, or move the header logic earlier in the request flow where that change matches the feature’s intended behavior. Then repeat the exact action that originally produced the warning.
Find the real source instead of editing the victim
wp-config.php
This file is loaded early and is a frequent place for accidental blank lines, pasted text, or an encoding mark. Inspect the area named by the warning and the file’s first and last characters. Keep database settings and other required values intact; the goal is to remove unintended output, not to rewrite the configuration.
Recently edited plugins
A plugin can emit text while it is being loaded, before WordPress has completed a login or redirect. Check the plugin file named in the warning and any file it includes. If the problem began immediately after an update or edit, temporarily revert that specific change using a backup or version-controlled copy, then test again.
Free tools Windows power users keep installed
One-click scans. No signup required.
Theme files
Theme templates normally produce the page body, so header operations placed after template output are too late. Inspect custom bootstrap files, theme functions, and files loaded before the failing action. A theme can also include a helper file that contains the actual stray output even when the warning names a different entry point.
Must-use plugins and included PHP files
Must-use plugins load automatically and can affect every request, including the login and administration areas. Follow each require or include chain until you reach the first file named by the warning. Do not stop at the file that happened to call the include; the included file may be where output starts.
Rank #3
Core files such as pluggable.php or wp-login.php
Core files often contain the header operation that exposes the problem. Unless the warning’s earliest output location is itself a core file, leave these files unchanged. Editing a later core line can hide the symptom temporarily while preserving the output that will break another request.
Output sources to remove
Whitespace around PHP tags
Characters before an opening <?php tag or after a closing ?> tag are sent as output. This includes a single space, a blank line, or a newline at the end of a file. Delete those characters and, where a file contains only PHP, consider omitting the closing tag entirely so that future edits cannot append text after it.
Accidental markup
HTML pasted into a configuration or library file is output immediately when that file is loaded. Move intentional markup into the template layer that is meant to render it. Remove accidental markup from files that should only define settings, functions, or hooks.
Debug statements
Temporary diagnostics are useful during development but can invalidate redirects and cookies when they run on a live request. Remove echo, print_r(), and var_dump() calls from the failing path. If you need diagnostic information, write it to a protected log rather than sending it to the browser; do not expose debugging output on a public site.
Warnings and notices emitted first
A PHP warning, notice, or other displayed error is output. Fix the underlying warning in the earliest file instead of treating the later header message as an independent defect. Once the first warning no longer appears, retest the original action because the header failure may disappear with it.
UTF-8 BOM characters
A UTF-8 BOM is not visible in ordinary code view but is interpreted as output by PHP. Resave the complete file as UTF-8 without BOM in a plain-text editor. Do not “fix” it by inserting output buffering or by adding arbitrary characters; the encoding should be corrected at the file level.
Making wp_redirect() work reliably
wp_redirect() sends a Location header. It cannot do that after the response body has started, so the function belongs in code that runs before templates or other visible output. A safe pattern is to perform the condition check and redirect in an early hook or request handler, then stop execution when the redirect is accepted:
if ( $should_redirect ) {
wp_redirect( $destination );
exit;
}The example only illustrates ordering and termination; use the destination and condition appropriate to your feature. Review everything that executes before this block, including included files and validation code. A debug print, an accidental template fragment, or a displayed warning in that earlier path is enough to make the redirect fail.
When diagnosing a redirect, distinguish two problems. If the warning says headers were already sent, trace the earliest output location first. If no output warning exists but the request continues after the redirect call, verify that the redirect branch is reached and that execution stops afterward. These are separate control-flow issues and require different fixes.
When a file may be corrupted
Use replacement rather than experimentation when a core file contains unexpected text, a configuration file has unclear edits, or the source location cannot be made trustworthy. Preserve the current file, obtain a verified backup or fresh WordPress copy, and compare the two versions. For configuration, copy only the required site-specific values into the clean file; do not overwrite them blindly.
Recommended Free Tools
Do not replace the entire installation simply because a later line is in pluggable.php or another core component. The warning’s first output location determines the scope of the repair. Broad replacement can remove legitimate plugin, theme, or configuration changes while leaving the original custom output untouched.
Retest without creating a second problem
After saving the corrected file, repeat the same action that triggered the warning. Test the specific workflow rather than assuming that a page load proves the fix. For a game site, that may mean logging in, opening the administration area, submitting an article form, or following a front-end redirect.
- Confirm that the original warning no longer appears.
- Check that the browser actually follows the redirect when one is expected.
- Verify that login cookies, form submissions, and session-dependent screens still work.
- Test both the public page and the administration path if the affected code is shared.
- Keep debugging information out of the public response; use protected logging in a non-public-safe environment.
If the warning persists, copy the new complete message. A different “output started at” location means the first issue was corrected and another output source now needs attention. If the same location remains, verify that the edited file is the one used by the active installation and that the editor actually saved it without BOM.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Choose the safest remediation path
| Situation | Self-repair is reasonable when… | Get experienced help when… |
|---|---|---|
| Access to the named file | You can open the exact PHP file and preserve a backup before editing. | You cannot access the path, hosting file manager, or deployment system that serves the site. |
| Invisible characters or encoding | Your editor can reveal or control UTF-8-without-BOM encoding and you can inspect the file as plain text. | You cannot determine whether a BOM or trailing bytes are present. |
| Type of file | The source is your own plugin, theme, or a recently edited configuration file. | The installation has unexplained core modifications or several interdependent customizations. |
| Known-good backup | You have a recent backup or version-controlled copy and can roll back safely. | No reliable restore point exists and the affected file contains critical production settings. |
| Urgency | The site remains usable and you can test in staging first. | Login, publishing, payment-related callbacks, or administration access is blocked on a live site. |
Anyone assisting should receive the complete warning, the first output location, the affected workflow, and a backup of the current files. That information is more useful than a request to “fix headers” without the paths and line numbers.
Common situations and targeted checks
The dashboard works, but a form submission redirects to the wrong page
Start with the handler that processes the form, then follow its includes. Look for output produced during validation before wp_redirect() runs. Remove that output and ensure the redirect branch exits after sending its header. Retest the same form with both valid and invalid input so that each branch is exercised.
Login shows warnings from wp-login.php
Treat the location after output started at as the lead. Check configuration, must-use plugins, and recently edited authentication-related code before touching the login core file. Once the earliest output is gone, verify that the login cookie is set and that the browser reaches the intended administration page.
A plugin update introduced the message
Compare the updated plugin files with the last known-good copy. Inspect the file and line named as the output source, including its first and last characters. If rolling back restores normal behavior, keep the rollback in place while the plugin change is reviewed; do not patch an unrelated core file to accommodate the update.
The warning appears only on one template
A template-specific include may emit output only on that route. Trace the include chain from the template to the first source location and inspect conditional branches that execute on that page. Test another route that uses the same header logic to determine whether the issue is localized or shared.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →The message disappears when debugging is disabled
Disabling visible debugging can hide the text that exposed the ordering problem, but it does not make the response sequence reliable. Find and remove the underlying output source, then use protected logs for diagnostics. Redirects, cookies, and sessions can still fail even when the warning is no longer displayed.
Quick Recap
Prevent the warning from returning
- Edit PHP in a plain-text editor and save files as UTF-8 without BOM.
- Keep configuration and library files free of markup and diagnostic prints.
- Omit unnecessary closing PHP tags in files that contain only PHP.
- Review the complete diff after plugin, theme, or configuration changes.
- Test login, redirects, cookies, and form submissions in staging before deploying.
- Keep a known-good backup of custom files and required configuration values.
- When a warning appears, preserve the complete message before refreshing or changing multiple files.
What not to do
- Do not edit the later core line merely because it appears in
pluggable.php,wp-login.php, or another WordPress file. - Do not add arbitrary whitespace, output buffering, or suppression rules as a substitute for finding the first output.
- Do not hide the warning as the primary fix; concealed output can still break redirects, cookies, and sessions.
- Do not replace broad portions of WordPress without preserving configuration and custom code.
- Do not test only a page view when the original failure involved login, a form, or a redirect.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
