Line Ending Converter (CRLF / LF)

Text files end their lines differently across platforms: Unix and macOS use a single LF, Windows uses CRLF, and classic Mac used a bare CR. This tool detects which you have, warns about mixed files, and rewrites everything to one consistent style.

A brief history of why this problem exists

Every modern line-ending problem traces back to typewriters. A mechanical carriage return (CR) moved the print head back to the start of the line; a line feed (LF) advanced the paper one line. Teletypes inherited both. When computing emerged, different systems chose different subsets:

• Unix (1970s): stripped the carriage return entirely — just LF (\n, 0x0A).
• Windows / DOS: kept both — CR+LF (\r\n, 0x0D 0x0A), matching the old teletype convention and matching what many protocols (SMTP, HTTP headers) still require.
• Classic Mac OS (pre-OS X): used CR alone (\r, 0x0D). macOS switched to Unix-style LF when it moved to a Unix foundation.

Today almost all source code should use LF, but the two-platform reality of Windows and Unix means files still cross the boundary constantly — through file shares, email attachments, copy-pasted content from the web, and repositories cloned on Windows.

How the conversion works safely

Conversion goes through a normalised intermediate so no input mix can corrupt the result:

1. Normalise:  replace every \r\n and every lone \r with \n
   (now the text uses only LF, whatever it started with)
2. Expand to the target:
   LF   → \n
   CRLF → \r\n
   CR   → \r

Detection counts CRLF first, then remaining lone CR and lone LF, so a \r\n is never double-counted. If more than one style appears, the tool flags the file as mixed.

Going through the LF intermediate prevents the most common corruption bug: naively replacing \r with \r\n on a file that already has CRLF endings would double up the \r, producing \r\r\n — a stray carriage return at the end of every line.

The real-world failures mixed line endings cause

Shell script shebang errors. A script beginning with #!/bin/bash\r (CRLF ending) will fail on Linux with /bin/bash^M: bad interpreter: No such file or directory. The ^M (carriage return) is invisible in most editors but very real to the kernel. Converting to LF fixes it immediately.

Git phantom diffs. If your repository has .gitattributes configured with * text=auto (which converts line endings on checkout), switching between Windows and Unix machines without consistent settings generates diffs that show every line changed — even when the content is identical.

Python and heredoc strings. A CRLF inside a Python multi-line string includes the \r character in the string value, which can break parsers, regex matches, and line-count comparisons.

CSV and data files. Some CSV parsers on Unix treat the trailing \r as part of the last column value in each row, producing mismatched column counts or garbage in the final field.

Which ending to choose

For any file going into version control, standardise on LF and add a .gitattributes to enforce it automatically across all contributors.