It usually appears right after someone has edited a file. A line of warning text sits across the top of the page, or across the login screen, and reads something like this:
Warning: Cannot modify header information – headers already sent by (output started at /home/account/public_html/wp-config.php:1) in /home/account/public_html/wp-includes/pluggable.php on line 1450
The paths and line numbers will be different on your site. Alongside the warning, you may find you cannot log in, saving a post leads to a blank screen, or a redirect simply does not happen. It looks alarming, but this is one of the most precise messages PHP gives. It tells you which file caused the problem and on which line, as long as you read the right half of it.
What “headers” are, in plain terms
Every page a server sends has two parts. First come the headers: short instructions for the browser, such as “set this login cookie,” “go to this other address instead,” or “this is an HTML page.” Then comes the content you actually see.
Headers must go first. The moment PHP sends any content at all, even one blank line or a single space, the headers are locked and sent with it. If WordPress then tries to set a cookie or redirect you, PHP refuses and prints this warning. That is why the symptoms are mostly about logins and redirects: those are the jobs that depend on headers.
Reading the message correctly
The warning names two files, and people very often fix the wrong one.
- “output started at … wp-config.php:1” is the culprit. This is the file and line where unwanted output began. This is the one to open.
- “in … pluggable.php on line …” is the victim. That is the WordPress core file that tried to send a header and could not. There is nothing wrong with it, and editing it will cause new problems.
So in the example above, the fix lives on line 1 of wp-config.php. If the “output started at” part names a plugin or theme file, that is where you look instead.
Common causes, most frequent first
Blank space before the opening PHP tag
A PHP file must start with <?php as its very first characters. A blank line or space above it is sent to the browser as content. This often happens when someone pastes code into wp-config.php or a theme’s functions.php using a web-based editor.
Blank space after a closing PHP tag
Some files end with ?>. Anything after it, including an extra empty line, becomes output. This is so common that widely used PHP coding standards recommend leaving the closing tag out entirely at the end of files that contain only PHP.
An invisible byte order mark
Some text editors save files as “UTF-8 with BOM,” adding three invisible characters at the very beginning. You cannot see them, but PHP sends them. The warning still points to line 1, which is confusing when the line looks perfect. Re-saving the file as “UTF-8” without BOM in a proper code editor fixes it.
A PHP warning or notice shown on screen
If error display is switched on, an unrelated warning from a plugin is printed onto the page, and that printed text then counts as output. You end up with two messages: the original warning, and this one underneath it. Fix the first and the second usually disappears.
Code that prints something too early
A plugin or snippet that uses echo or prints HTML while WordPress is still loading, rather than during the proper display hook, will trigger this. Custom snippets added to functions.php are the usual source.
Fixing it step by step
You will be editing core configuration files, so keep a backup of the site, and before each change download a copy of the exact file you are about to edit. If an edit makes things worse, you put the old copy back.
- Copy the full warning. Paste it into a note. You need the “output started at” path and line number.
- Open that file in a real code editor, not a word processor. Free editors such as Visual Studio Code or Notepad++ show line numbers and file encoding. Download the file by FTP or the host’s file manager, or use the host’s built-in code editor if it has one.
- Look at the named line. If it is line 1, delete everything before
<?php, including blank lines and spaces. If it is the last line, remove anything after the final?>, or remove the closing tag itself if the file is pure PHP. - Check the encoding. In your editor’s status bar or “Save with encoding” option, choose UTF-8 without BOM, then save.
- Upload the corrected file and reload the page. If a new warning appears with a different “output started at,” repeat the process for that file. Occasionally there is more than one.
- If the culprit is a plugin file, do not edit it, because an update would overwrite your change anyway. Rename that plugin’s folder in
wp-content/pluginsto deactivate it, confirm the warning goes away, then check for an update or report the problem to the developer. - If the culprit is your theme, look for recently added snippets in
functions.php. If you are not on a child theme, consider moving custom code into one, or into a small site plugin, so it is easier to switch off. - Turn off on-screen errors on a live site. In
wp-config.php, keepWP_DEBUG_DISPLAYset to false and send errors to the log instead. Our post on switching WordPress debug mode on and off safely shows the lines to use.
When you cannot see the warning at all
On a well set up live site, error display is switched off, so this warning never appears on screen. You only see the side effects: a form that saves but leaves a blank page, a redirect that never happens, or a login that will not stick. The warning is still being recorded, though.
If logging is enabled, open wp-content/debug.log and search for “Cannot modify header information”. Your hosting panel’s PHP error log is the other place it tends to appear. The entry has the same two paths as the on-screen version, so the same reading rule applies: open the file named after “output started at.”
Stray output can also break the background requests the block editor relies on. The editor expects clean data back from the server, and a few extra characters at the start are enough to spoil it. When that happens the editor may complain that the response was not valid JSON, rather than showing any header warning. Our post on the invalid JSON response message covers that error and its other causes.
Why it often stops you logging in
Logging in depends on WordPress setting cookies, and cookies are headers. When output arrives first, the cookie is never set, so the login page just reloads or shows a note that cookies are blocked due to unexpected output. If you are stuck in that situation, our article on the login page that keeps reloading covers the other reasons it happens as well.
When editing a file caused worse problems
If the edit that introduced the stray space also introduced a typo, you might see a parse error or a “critical error” message instead of, or as well as, this warning. Parse errors name a line too, and our guide to “Parse error: syntax error, unexpected” explains how to read them. If the whole site now shows “There has been a critical error on this website,” our critical error fix service deals with that directly.
And since wp-config.php holds your database password and security keys, take care where copies of it end up while you work. Our article on keeping wp-config.php safe covers why that file deserves extra attention.
Habits that prevent it
- Edit PHP files in a code editor that shows encoding and line numbers, never in a word processor or a rich-text email.
- Avoid editing live files through the dashboard’s theme and plugin file editors. A typo there can lock you out of the dashboard you are editing from.
- Leave the closing
?>off files that are pure PHP. - Keep error display off on the live site and logging on, so harmless notices never reach the page.
- Write a short note whenever you change
wp-config.phporfunctions.php: what, when and why. When a warning appears days later, that note is the first place to look.
This warning is one of the easier entries in our WordPress errors guide once you know which file to open. If the “output started at” path points somewhere you do not recognise, or you would rather not edit configuration files on a live site, our WordPress bug fixing service can take it from there. Send us the full warning text; we back up the site, correct the file, and tell you which line it was and how it got there.
Next in this series: Destination Folder Already Exists: Fix WordPress Installs
