WordPress 'Cannot Modify Header Information - Headers Already Sent' Fix (2026)
Disclosure: some links on this page are affiliate links. We may earn a commission at no extra cost to you. How we test and rate hosts.
"Warning: Cannot modify header information - headers already sent by (output started at /home/user/.../wp-config.php:1) in /wp-includes/pluggable.php on line 14xx." Pluggable.php is the victim, not the culprit. The real culprit is in the parentheses: one invisible character of output somewhere. Here's how to find and kill it.
Step 1: Read the Right Part of the Warning
Ignore "pluggable.php on line X" - that's where WordPress tried to send a header. What matters: output started at [file]:[line]. That file and line is where the stray output lives. wp-config.php line 1 and functions.php are responsible for most cases.
Step 2: Fix wp-config.php (The Usual Suspect)
- 1.Open wp-config.php via FTP in a real code editor (VS Code, Notepad++ - not Windows Notepad)
- 2.Check character position 1,1: the file must start with the PHP open tag - delete any space, blank line, or invisible character before it
- 3.Scroll to the end: if there's a closing PHP tag, delete it and any blank lines after - the closing tag is optional and trailing whitespace after it is a classic trigger
- 4.Save as UTF-8 without BOM (in Notepad++: Encoding menu; in VS Code: click encoding in status bar). The BOM is 3 invisible bytes of output at line 1
Step 3: Check functions.php and Recently Edited Files
If wp-config is clean, apply the same three checks to the file named in the warning - usually the active theme's functions.php or a file you edited just before the warning appeared: nothing before the open tag, no closing tag at EOF, UTF-8 no BOM. If the named file is inside wp-content/plugins/[name]/, that's a plugin bug - update or replace that plugin instead of editing it.
Step 4: Find Echo Statements Before Redirects
Custom code with echo, print, or var_dump running in functions.php or a plugin before WordPress sends headers causes the same warning - and the "output started at" line will point exactly at it. Remove the debug output or move it inside a hook that runs after headers.
Why You Shouldn't Just Hide the Warning
Turning off display_errors hides the symptom but headers still fail silently: logins loop, redirects break, contact forms submit to blank pages. Fix the whitespace. Related session symptom: wp-admin login redirect loop. If editing files broke something else: syntax error fix.
Done Fighting PHP Quirks Alone?
Bluehost's 24/7 phone support will actually look at your wp-config with you. $3.99/mo, free domain, free migration.
Get Bluehost from $3.99/moWhat are you building?
Tell us about your project so we can match the perfect hosting plan.
Hosting Cost Calculator
See exactly how much you'll spend on hosting over time. Compare Bluehost vs popular alternatives and discover your potential savings.
Used to calculate transaction fees (Shopify charges 2% on sales)
Frequently Asked Questions
What does 'headers already sent' mean?
PHP must send HTTP headers (cookies, redirects) before any output. Something printed output - usually invisible whitespace or a BOM byte - before WordPress tried to send a header. The warning names the file and line where the output started.
Why does it mention pluggable.php?
pluggable.php is where wp_redirect and auth functions live - it's where the header send fails, not where the bad output is. Read the full warning: 'output started at /path/file.php:LINE' names the real culprit.
What usually causes it?
Blank lines or spaces before the opening PHP tag or after the closing tag in wp-config.php or functions.php, a UTF-8 BOM saved by a text editor, or an echo/print statement that runs before a redirect.
How do I fix it?
Open the file named in 'output started at'. Remove any whitespace before the PHP open tag, delete the closing PHP tag entirely at the end of the file (it's optional and causes this), and re-save as UTF-8 without BOM.
Is this error dangerous?
The warning itself is harmless, but it breaks every redirect - including the login flow, form submissions, and 'post published' redirects. It can also leak your server path to visitors, so fix it rather than hiding it.
The named file is inside a plugin - what then?
A poorly coded plugin printing output early. Update it first; if the warning persists, deactivate and replace it. Don't edit plugin files - your fix dies on the next update.
Ready to launch?
Get Bluehost from $3.99/month with a free domain, free SSL, and 30-day money-back guarantee.
Related Articles
Bluehost vs Competitors: The Technical Deep Dive
We ran 47 benchmarks over 90 days. Here's the raw data on why Bluehost dominates.
Fix ERR_TOO_MANY_REDIRECTS in WordPress (2026): The 6 Real Causes
ERR_TOO_MANY_REDIRECTS means an infinite redirect loop. Match your Site URLs, fix Cloudflare SSL mode, reset .htaccess, kill plugin conflicts - step-by-step with code.
WordPress 403 Forbidden Error: 7 Fixes That Actually Work (2026)
403 means the server understood you but refuses to serve the page. Fix file permissions (755/644), regenerate .htaccess, kill security plugin blocks - in the right order.
Fix 502 Bad Gateway in WordPress (2026): Diagnose First, Then Fix
502 means the gateway got a bad response from your server - usually PHP timeouts, CDN issues, or overload. A 9-step diagnostic workflow from browser checks to server logs.
Fatal Error: Maximum Execution Time Exceeded - 6 Fixes (2026)
max_execution_time kills slow updates at 30-60s. Fix the culprit plugin/theme first, then raise the limit via wp-config, .htaccess or php.ini - with exact code.
HTTP Error Uploading Images in WordPress: 9 Fixes Ranked (2026)
The vague 'HTTP error' on image upload usually means memory limits or Imagick. Fix order: rename the file, bump memory, force GD library, check permissions - with code.