The warning means PHP tried to send a header—usually for a redirect, cookie, or session—after some other output had already reached the browser. Find the file and line identified after output started at, remove the output or invisible characters there, save the file as UTF-8 without BOM, and then retest the failed action. The later file named in the warning is usually where the header operation failed, not where the problem began.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
What “Cannot modify header information” means
HTTP headers have to be sent before the response body. PHP can use functions such as header(), and WordPress can use redirects, cookies, and session headers, only while the header block is still open. Once PHP has emitted text, markup, a warning, or even an invisible encoding marker, the response has started and new headers cannot be added.
As an Amazon Associate I earn from qualifying purchases.
The PHP manual states: “You can’t add any more header lines using the header() function once the header block has already been sent.” WordPress code often encounters the same restriction through wp_redirect(), login cookies, nonce cookies, session initialization, or other functions that eventually call PHP’s header functionality.
The output can be visible, such as an accidental echo, or invisible, such as a blank line before the opening PHP tag or a UTF-8 byte-order mark (BOM). The browser may show a warning, a failed redirect, a login loop, missing cookies, or a partially rendered page.
Read the warning in the right order
A typical message contains two locations. For example:
Warning: Cannot modify header information - headers already sent by (output started at /var/www/html/wp-config.php:34) in /var/www/html/wp-login.php on line 42Line 34 of wp-config.php is the likely source of the first output. Line 42 of wp-login.php is where WordPress later attempted a header operation and was refused. Treat the first location as the lead and the later location as the victim.
Free tools Windows power users keep installed
One-click scans. No signup required.
| Warning fragment | What it tells you | First action |
|---|---|---|
output started at /path/file.php:line |
The earliest location PHP reported as output | Open that file and inspect the named line, the file beginning, and the file ending |
in /path/other-file.php on line ... |
The later header, redirect, cookie, or session call that failed | Do not edit this file until the earlier source has been checked |
headers already sent |
PHP has already begun the response body | Look for whitespace, markup, debug output, BOM bytes, or an earlier warning |
Copy the complete warning before changing anything. Paths and line numbers can change after an edit, and the complete message preserves the evidence needed to trace the first output.
Step-by-step fix
- Capture the full error. Include the text before and after
headers already sent, the complete path, and both line numbers. If the warning appears only briefly, copy it from the PHP or WordPress log instead of relying on memory. - Open the file after
output started at. Use a plain-text editor or your host’s code editor. Go to the reported line, then inspect the first characters in the file and everything after the final PHP code. A line number is a starting point, not a guarantee that the visible problem is on that exact line; an invisible character immediately before it may be responsible. - Remove unintended output. Delete blank lines or spaces before
<?php, after a closing?>, or between PHP sections when they are not required. Remove accidental HTML, diagnostic text, and debug calls such asecho,print_r(), andvar_dump()that execute before the redirect or header operation. - Check the files that were recently changed. Start with
wp-config.php, the active theme, recently edited plugins, must-use plugins, and PHP files included by those components. A file named in the warning may be included indirectly, so inspect the include chain when the first location is not obvious. - Save without a UTF-8 BOM. Choose the editor’s UTF-8 encoding option that explicitly says “without BOM” or “UTF-8 (no BOM).” Do not use a rich-text editor, word processor, or editor that silently adds formatting. Close and reopen the file to confirm the selected encoding before uploading it.
- Protect uncertain files. Before replacing a configuration or core file, preserve a copy of the current file and record any site-specific values. If the file is corrupted or contains changes you cannot verify, restore a known-good backup or replace it with the corresponding file from a fresh WordPress download, then reapply only the required configuration values.
- Review the failed header operation. Check the code that calls
wp_redirect(),header(), cookie functions, or session functions. It must run before templates, markup, debug output, or warnings are emitted. After the source is corrected, repeat the original login, admin navigation, form submission, or redirect that exposed the warning.
Find the output that started the response
Whitespace around PHP tags
The most common cause is a space, newline, or other character before the opening <?php tag or after a closing ?> tag. Open the file in a plain-text view rather than a visual editor, place the cursor at the very beginning, and remove anything before <?php. At the end, remove trailing characters after the PHP code. In files that contain only PHP, leaving out the closing ?> tag avoids accidentally appending whitespace later.
Do not remove meaningful output from a template simply because it is visible. The goal is to ensure that code requiring headers executes before that template output, not to strip legitimate page content.
UTF-8 BOM characters
A UTF-8 BOM is an invisible byte sequence at the beginning of a file. PHP can interpret it as output, so the warning may persist even when the file appears to begin directly with <?php. Re-save the file as UTF-8 without BOM and upload it again. If your editor does not expose encoding choices, use another plain-text editor that does; guessing based on what the file looks like in a browser is unreliable.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsDebug output, markup, and accidental text
Search the implicated file and its included files for temporary diagnostics and test text. Calls such as echo, print_r(), and var_dump() can send output before a redirect. So can an HTML fragment copied into a PHP file, a closing tag followed by explanatory text, or a warning generated by code that runs earlier. Remove the diagnostic code after you have recorded the information it provided.
Earlier PHP warnings and notices
A notice, warning, or other PHP message can itself become output before WordPress reaches a redirect or cookie call. If the header warning is accompanied by another PHP message, fix the earliest message first. In a non-public testing environment, enable logging so errors are recorded without displaying them to visitors; do not expose detailed paths or diagnostics on a live site.
Audit the WordPress files most often involved
wp-config.php
Because WordPress loads wp-config.php early, one stray byte there can affect login, administration, redirects, cookies, and front-end requests. Inspect the exact line reported, then inspect the file’s first and last bytes. Keep database settings, authentication keys, table prefixes, and other required values intact while removing only unintended characters. If you cannot establish what a damaged configuration file should contain, use a verified backup rather than reconstructing it by trial and error.
Recently edited plugins and themes
Start with the component changed immediately before the warning appeared. Check its main PHP file and any helper file it includes. Look for output executed at load time, not only inside a function: a test message at the top of a plugin file can run as soon as WordPress loads the plugin. In a theme, inspect setup files that run before templates and any code handling form submissions or redirects.
Rank #3
Must-use plugins and included PHP files
Must-use plugins load automatically and can produce output before ordinary plugins or theme code runs. Include files can have the same effect even when their names do not appear in the visible page. Follow the include statements from the first reported file and inspect each included PHP file for whitespace, BOM characters, debug calls, and accidental markup.
WordPress core files
Do not edit a core file merely because the later location in the warning is wp-login.php, pluggable.php, or another core path. Core is often where WordPress finally attempts the header operation, while custom code produced the earlier output. Only replace a core file when you have evidence that it is corrupted or differs from a known-good WordPress copy, and preserve a backup before doing so.
Make redirects and header calls execute safely
Place wp_redirect() before output
A redirect must be decided before WordPress sends page markup. The basic sequence is:
<?php
if ( $should_redirect ) {
wp_redirect( $destination_url );
exit;
}
The important properties are ordering and termination: no output may run before the redirect, and execution should stop after a successful redirect decision so later template code does not continue writing the response. The exact condition and destination depend on your application; do not paste this example into a live workflow without adapting and testing it.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Check cookies and sessions in the same way
Cookie and session operations also modify headers. If a login cookie is missing or a session fails after you remove the visible warning, inspect every code path that runs before those operations. A page can appear to load while authentication or state persistence remains broken if the source output has not been eliminated completely.
Do not treat output buffering as the primary repair
Buffering can change when output is sent, but it does not remove the stray bytes, debug output, or encoding problem that caused the warning. It can also hide an output source and leave redirects, cookies, or sessions unreliable. Trace and remove the first output instead of suppressing the symptom.
Repair a damaged file without losing site settings
When a file contains unexplained characters or appears corrupted, compare it with a known-good backup or the matching file from a fresh WordPress package. Preserve a copy of the current version for rollback and for recovering custom settings. For wp-config.php, retain the site’s database connection values, authentication keys, table prefix, and any intentional constants. For a plugin or theme file, preserve documented customizations and verify that the replacement matches the installed version.
After replacement, upload the file in binary-safe mode if your host’s transfer tool offers a choice, and confirm its encoding in the editor. A fresh copy helps only when the replacement is the correct version and the original site-specific values are restored deliberately.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Retest without exposing sensitive diagnostics
- Perform the same action that originally failed: sign in, open the affected admin screen, submit the form, or follow the redirect.
- Check that the browser reaches the expected destination and that login state, cookies, and sessions persist.
- Review the PHP and WordPress logs for a new earliest output location. A changed line number can indicate that the first problem was fixed but another file still emits output.
- Repeat the test in a staging or otherwise non-public environment first when the change affects configuration or core files.
- Once behavior is correct, keep detailed error display disabled for public visitors while retaining appropriate server-side logging.
Common wrong turns
- Editing the later core line: The line in
wp-login.phporpluggable.phpis commonly the failed header call. Trace the earlieroutput started atlocation first. - Deleting random blank lines throughout the site: Change the file identified by the warning and inspect its boundaries and reported line before touching unrelated files.
- Hiding the warning: Suppression can conceal the output source while redirects, cookies, and sessions continue to fail.
- Using a word processor: Rich-text applications can insert formatting and encoding bytes that PHP treats as output. Use a plain-text editor.
- Removing legitimate template markup: Page content is not automatically a bug. Move header-dependent logic earlier or remove only unintended output.
- Replacing core without a backup: A replacement can erase local configuration or custom changes. Preserve the original and restore required values deliberately.
Choose self-repair or outside help
| Situation | Self-repair is reasonable when… | Get help when… |
|---|---|---|
| Access | You can safely access the named PHP file and make a reversible edit | You cannot reach the file, hosting access is failing, or the site is locked out |
| Cause | The problem is visible whitespace, a debug call, or an encoding setting you can verify | The output is generated through several includes or the source remains uncertain |
| File type | The affected file is custom plugin or theme code with a known backup | The file is core or configuration code with unknown local modifications |
| Recovery | A known-good backup exists and you can test in staging | No backup exists and a failed edit could affect login, redirects, or database access |
| Urgency | The broken workflow can wait for a controlled test | Customers cannot log in, forms cannot submit, or administration is inaccessible |
Whether you fix it yourself or ask for support, provide the complete warning, the first reported path and line, the files changed immediately beforehand, and whether a backup or staging copy is available. That information is more useful than reporting only that a WordPress core file shows a header warning.
Prevent the warning from returning
- Use a plain-text editor for PHP and save files as UTF-8 without BOM.
- Keep PHP-only files free of closing tags when there is no need to switch into HTML.
- Remove temporary
echo,print_r(), andvar_dump()statements before deploying. - Run redirect, cookie, and session logic before templates or any other response output.
- Maintain verified backups of
wp-config.php, custom plugins, themes, and deployment versions. - Test changes in staging and inspect logs while detailed diagnostics are kept away from public visitors.
- When a warning appears, preserve the full message and follow the earliest output location rather than editing a later core file.
When the warning keeps appearing
The reported file looks clean
Recheck the file’s encoding and inspect its first bytes with an editor that can identify BOM characters. Then trace files included before the reported line. An included file can emit output while the visible file appears correctly formatted.
The line number changes after each edit
Use the newest complete warning and start again from its current output started at location. Removing one source can reveal a second source that was never reached in the original request.
The warning is gone but the redirect still fails
Inspect the redirect condition and destination separately. Confirm that the redirect code is reached before any output and that execution stops afterward. Also check cookie and session calls on the same request path; fixing output timing does not correct an unrelated redirect logic error.
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 site cannot be tested safely on production
Restore the file in a staging copy or another controlled environment, reproduce the original action, and review logs there. Once the exact change is verified, deploy the smallest reversible fix to production and repeat the original workflow.
The practical diagnosis
“Cannot modify header information” is a timing error, not usually a reason to alter WordPress core. The reliable path is to read the complete warning, investigate the earliest output started at file and line, remove unintended output or BOM bytes, save as UTF-8 without BOM, and ensure redirects, cookies, and sessions run before any response body. Replace a damaged file only from a verified source, test the original workflow, and keep diagnostics out of the public response.
Quick Recap
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.
