CRLF vs LF And the Two Bytes That Break Things

Two characters nobody can see decide whether a file works. Windows ends a line with CRLF, a carriage return followed by a line feed. Unix, Linux and macOS all use LF alone. Nothing on screen tells you which you are holding. When it matters, the error message never mentions line endings, which is why this costs people so much time.

It matters more with mail than with almost anything else, in the direction people least expect. A mailbox on a Mac carries Windows style endings. That is correct rather than a mistake somebody made.

Where CRLF And LF Came From And Why Both Survived

On a teletype, moving to the next line took two separate movements. The carriage went back to the left, then the paper rolled up by one line. Two mechanical actions, so the character set gave each one its own code.

Different systems then chose differently. None of them changed their mind.

Windows      Hello<CR><LF>World<CR><LF>      0D 0A
Unix, macOS  Hello<LF>World<LF>                0A
Classic Mac  Hello<CR>World<CR>                0D

Apple switched sides in 2001. Classic Mac OS used the carriage return alone. Mac OS X was built on Unix and took the line feed, so files from before that era behave differently from files after it. Anything old enough to predate the change can still turn up using neither of the current conventions.

Why Mail Insists on CRLF

This is the part that catches people working with mail files, because it runs against every other habit.

The internet message format demands both characters at the end of every line. Not as a preference. The specification says lines are terminated by a carriage return followed by a line feed. Mail servers were built on that promise.

The MIME boundary is where it shows first. A boundary marker has to match exactly for the parts of a message to be found. Change the line endings and the match can fail, so a message that held three attachments arrives holding none, with nothing to suggest what happened.

What a Stray CR Does to a File

The character does not vanish when a program does not expect it. It becomes part of whatever was on that line, which is where the strange errors come from.

Every row has the same shape. The visible part is correct and something invisible is attached to it, so the error describes a thing that plainly exists and appears to be spelled right.

That last row is the one worth recognising on sight. It means a Windows file being read by something that wants line feeds, nothing more. It is not damage and nothing needs repairing. The file is fine and the reader is strict.

Why Git Reacts So Badly to Line Endings

Anybody who has opened a change and found every line marked as modified has met this.

Version control compares lines. Change the ending on all of them and every line differs from the stored version, so the whole file reads as rewritten. The visible text is identical and the comparison is still correct, because the bytes really did all change.

412 lines removed
412 lines added

every line touched
nothing readable
  actually differs

the file was opened
  and saved by an
  editor with different
  defaults

two bytes became one
  on every line

Checking Line Endings Without Changing Anything

1. Read the editor status bar. VS Code shows CRLF or LF in the bottom right. Notepad++ shows it too. Both let you switch. Looking costs nothing.
2. Use the file command on a terminal. It reports CRLF line terminators when they are there and says nothing when they are not, which is the answer either way.
3. Look at the hex if you want certainty. 0D 0A is both characters. 0A alone is a line feed. This is the only method that cannot be wrong.
4. Check what the destination needs before converting. A server, a script or version control wants line feeds. Mail and older Windows tools want both. Converting without asking is how the trouble starts.

Converting is safe and reversible in one direction only. Going from both characters to one is a clean removal. Going back adds a carriage return to every line, including lines that never had one, so a file that mixed the two conventions comes out consistent rather than restored.

Where Line Endings Meet the Other Invisible Problem

Line endings and character encoding cause similar trouble for a similar reason. Both are decisions about bytes that a file usually does not declare. Both stay invisible until something strict reads it.

They are not the same problem. Encoding decides which character a byte means. Line endings decide how many bytes end a line. A file can be wrong on one and right on the other. The symptoms look nothing alike.

Where the file happens to be a mailbox, both rules apply at once and pull opposite ways. The encoding is declared per part and should be honoured. The line endings are fixed by the specification and should be left alone. Our file viewers read both as they are rather than normalising anything. The converters keep whichever endings the destination format requires.