In PHP, what causes the "Cannot modify header information - headers already sent" warning, and how do you fix it?

## Why there is a deadline for headers An HTTP response is a status line, then headers, then the body. PHP collects the headers you set with `header()`, `http_response_code()` and the cookie functions in a list, and sends that list **once**, immediately before the first byte of body output reaches the server API. After that point the headers are on their way to the client and cannot be changed. "Output" means anything that reaches the output layer: `echo`, `print`, HTML outside `<?php ... ?>`, `var_dump()`, `printf()`, and PHP's own error messages when they are displayed. ## What the warning looks like and what it means Calling `header()` after output produces an `E_WARNING`: "Cannot modify header information - headers already sent by (output started at /srv/admin/src/bootstrap.php:1)" Three things to notice: - the **file and line in parentheses** are where output started, not where `header()` was called; - `header()` returns nothing and does **not** throw, so execution continues; - the header is simply dropped, so a redirect that "does nothing" is often this bug with `display_errors` off. `http_response_code()` reports the same condition with its own warning ("Cannot set response code - headers already sent") and returns `false`. ## The usual culprits | Cause | Where to look | |---|---| | `echo` or HTML before the header call | the controller or template order | | blank line or space before `<?php` | first line of the file named in the warning | | newline after a closing `?>` | the end of an included config or class file | | UTF-8 byte order mark (3 invisible bytes) | editor encoding of the named file | | a displayed notice or warning | any warning printed before the call while `display_errors` is on | | debugging output | a forgotten `var_dump()` | The line number is the fastest clue: line 1 of a file usually means a BOM or leading whitespace, and the last line means a stray newline after `?>`. ## Checking in code `headers_sent(&$filename = null, &$line = null): bool` returns `true` once headers have gone out and fills the two variables with the output start location. It is useful in a front controller to fail loudly ("cannot redirect, output started at ...") instead of silently. ## Diagnosing a redirect that silently does nothing When a save-then-redirect in an admin panel leaves the user on a blank or half-rendered page: 1. Look in the **error log** for "headers already sent"; with `display_errors` off it never appears on screen. 2. Read the **output started at** location, not the line of the `header()` call. 3. Open that file and check line 1 for a BOM or whitespace, the last line for text after `?>`, and the lines around it for `echo` or debug output. 4. If the location is a template, the handler rendered before deciding; move the redirect decision above the rendering. 5. Reproduce with `output_buffering` off, so the bug cannot hide behind a buffer. ## Fixing it properly 1. **Decide the response first, render second.** Do the work, choose the status, set headers or redirect, and only then produce HTML. 2. **Omit the closing `?>`** in files that contain only PHP; a trailing newline after it is output. 3. **Save files as UTF-8 without a BOM.** 4. **Keep `display_errors` off in production** and log instead, so a warning never becomes output. 5. **Remove debug output** before committing. ## Why output buffering hides the bug Both shipped `php.ini` files set `output_buffering = 4096`. With that, early output is held in a 4 KB buffer, and headers are not sent until the buffer is flushed. A handler that echoes a little text and then redirects "works" - until the early output grows past 4096 bytes, or the code runs under a configuration without the buffer (the compiled-in default is `0`, and the CLI forces it off). Relying on the buffer turns a clear error into an intermittent one; fix the order instead, and use explicit `ob_start()` only where capturing output is the actual goal.