Last updated 1 July 2015. Created on 28 March 2003.
Edited by dman, Patricia Barden, catch, LeeHunter. Log in to edit this page.

This error also presents as "Cannot modify header information" depending on PHP version.

In short, it means that somewhere in the code, something was printed to the browser before Drupal had finished preparing the page. This is most often caused by custom or modified code contributed from sources outside Drupal, so inspect your uniquely added code (including themes) first..

If you get a "Headers already sent" error, there are three likely causes.

If this error is not the first error message on the page, then it is most likely a 'avalanche effect' of previous errors and you may ignore it. Instead, focus on fixing the errors before it. When you fix the first error message(s), the "Headers already sent" error(s) will most likely disappear.

Text editors sometimes insert a UTF-8 byte order mark at the top of a file. In this case, the error message will usually say that "output started" at line 1 of some file. To fix this, configure your text editor to save the file without a byte order mark.

However, if you get an error "Headers already sent" as the first error and it tells you the error is near the end of a file (check which file "output started at" points to), that probably means that there are extra spaces or lines after a closing ?> php tag. In Drupal coding standards, it is strongly recommended (for this very reason) that PHP files should not have any closing ?> tags . Delete them, and everything should work fine.

Extra whitespace being added probably is caused by a bad unpacking program and / or a non-compliant editor (Windows Notepad or Wordpad, Mac TextEdit) adding it.

Problems with "headers already sent" can also be caused by having a blank line at the end of *.inc files. Drupal or more likely PHP seem to have problems with extra spaces here and there.

Check all *.inc files to make sure there are no closing php ?> tags in any of them. Closing php ?> tags are not needed in your *.inc files. Also, check all *.php files to make sure there are no blank lines at the beginning or at the end of the file.

If the error message indicates that this is caused by a module, disable modules one by one to find out which one is causing the problem.

This can also be caused by UTF-8. If a website is coded in ASCII and php files are being saved as UTF-8, it can cause this message. If the website and DB are both UTF-8, it should be ok to save php files as UTF-8.

Additionally, this error message is related to the "output_buffering" variable in php.ini. If output_buffering is set to some cache, the server will send headers with delay (or modify them shortly after they are sent), and this error will not be tripped. But, if output_buffering is set to 0 or not at all, then headers can be sent at only one moment and, if there's bad code, it will trip this error message. To sum up, turning on the "output_buffering" variable in php.ini fixes this problem.


Don't get paranoid, but if you see this on a site that was previously working well, this could be a symptom of non-drupal code injection. It's not uncommon for hackers who have compromised a server to run scripts that automatically inject HTML code into any *.php files they can find. Often by inserting spam links into page footers etc. Occasionally, this will have the side effect of breaking the code execution, or producing this error. Though rare, this error appearing on a previously stable site has sometimes led to a hack being discovered.
To test for this fully, the only real solution is to compare your current live code with the official version. In practice, checking *timestamps* on the files on the server can provide clues also. Search elsewhere for instructions on recovering from (and preventing) such hacks.

Looking for support? Visit the forums, or join #drupal-support in IRC.


roleychiu’s picture

One of the more common errors results from leaving hard returns at the very bottom of your template.php file. Be sure to clear all spaces and returns from the very bottom of your template.php file to avoid this easy to make error.

hey_germano’s picture

If you're using the drupal_json function anywhere, and the error says something like "... (output started at /path/to/your/site/includes/", try adding an exit(); right after your drupal_json call.

I was seeing this error on some AJAX requests, seemingly at random, and only on a dev server where PHP output buffering isn't enabled. So enabling output buffering there probably also would've solved this, but if that's not an option (like in my case), check around for drupal_json.

irudayarajisawa’s picture

Additionally these error is related to some unwanted return statements. In my module after prompt for downloading a file these error has occurred.
Warning: Cannot modify header information - headers already sent in drupal_send_headers() (line 1211 of /usr/share/drupal/includes/

Fixed: After prompting for download of a file i have given a return statements. Which caused these error. Remove it. Everything works fine.

stevep’s picture

in my case I received the "Headers already sent ..." error messages because I'd disabled comments and blog modules (even though there were blog posts on the website).

Re-enabling the modules resolved the problem, for me.

lvaldeon’s picture

After a while trying to avoid Cannot modify header information, I change encoding to UTF-8 without BOM in the called in module.module
'file' => '',
and works!
It doesn't work with UTF-8.

riverrat’s picture

I have a similar problem with the error message

Warning: Cannot modify header information - headers already sent by (output started at /home/french2/public_html/ in drupal_goto() (line 703 of /home/french2/public_html/

However the only files that I have knowingly changed are the CSS files in ly sub theme, based on OMEGA.
If anyone can help it is driving me mad as it is triggered several times a minute!

SevyX’s picture

This has just happened to a site I run and nothing has been changed, so not much of a clue to where the error might lie. Has anyone else seen this arise recently and found out what it is?? It also prevents updating the site.

dilipsingh02’s picture

Today I have update my Drupal core 7.32 to 7.38 and then I got this issues on my site.

Warning: Cannot modify header information - headers already sent by (output started at in drupal_send_headers() (line 1236 of

sfcamil’s picture


Same problem after update to drupal-7.39:

Warning: Cannot modify header information - headers already sent by (output started at ... .... /includes/ in drupal_goto() (line 698 of ... ....  /includes/

Apparently everything ok but log messages is full of this message. Someone found a solution ?
Thx all.

hiramanpatil’s picture

Getting this message in error log:-

Warning: session_start(): Cannot send session cookie - headers already sent by (output started at /xxx/yyy/zzz/includes/ in drupal_session_start() (line 287 of /xxx/yyy/zzz/includes/

Please let me know if anyone has found solution to this issue.

angood’s picture

error code to I troubleshooted it down to deleting and echo variable line of code and without echoing it worked

eric.toupin’s picture

Just adding another possible solution. I ran into this error and couldn't find a solution on this thread. I had recently added a new dependency to the .info file of one of my custom modules, after said custom module had already been installed and enabled. The new dependency I added in the .info was already installed and enabled, too.

This error was introduced along with the page content being rendered 3 to 4 times per page load. Disabling and re-enabling my custom module, which I'd added a dependency to, fixed the problem.

WebWalker3D’s picture

While it may not be relevant to everyone it certainly is worth looking into as a potential cause:

In my case, the issue was related to having a module "installed twice", or at least having the module located in two separate spots. The end result is fun behavior where Drupal doesn't know which code to execute, and attempts to do the same thing twice essentially.

If you're seeing this error, check for duplicate modules, and remove the duplicates.

Half Full or Half Empty, it's Still a Glass...


EeluSamuel’s picture

Line of code before correction

if($_SESSION['user'] && $_SESSION['pass'])

Line of code that worked

if($_SESSION['user'] && $_SESSION['pass'])
	echo '

I noticed that using;
-header("Location:target.html"); to redirect causes that error
- its better to use echo '


'; to redirect.

upunkt’s picture

Since it can be tricky to find the issue causing this warning, I suggest leaving debugging code in places according to your dblog message. The messages I received always contained a reference to /includes/ and to /includes/ line 1490.

The latter is header($header_names[$name_lower] . ': ' . $value);

So I put this watchdog('Header',$header_names[$name_lower] . ': ' . $value); in the line after and waited for log entries. Once they showed up it was easy to identify which part of my custom code or configuration was causing the trouble.

In my case it's been a permission problem with a folder inside the private:// directory, where I exported Drupal Commerce views-reports via Rules. Hope this helps.