CRLF↔LF Line Break Converter
Detect which line-ending style your text uses and convert between Windows-style CRLF and Unix-style LF. This converts the line-ending style, it does not remove line breaks like a line-break-stripping tool would.
About the CRLF↔LF Line Break Converter
Different operating systems end lines differently, Windows traditionally uses a carriage return plus line feed (CRLF, \r\n), Unix, Linux, and modern macOS use just a line feed (LF, \n), and old classic Mac systems used a lone carriage return (CR, \r). Files edited across multiple systems can end up with a mix of all three, which sometimes breaks scripts, diffs, or version control. This tool counts exactly how many of each type are present, then normalizes the whole text to one consistent style.
- Detection, counts CRLF, lone LF, and lone CR occurrences separately so mixed files are visible.
- Convert to LF, replaces every CRLF and lone CR with a single \n.
- Convert to CRLF, first normalizes to LF internally, then converts every \n to \r\n, avoiding accidental double conversion of existing CRLFs.
- Byte difference, CRLF line endings take one extra byte per line compared to LF, shown as a stat chip after conversion.
Why line endings diverged in the first place
The split traces back to physical teletype hardware, moving to a new line meant two separate mechanical actions, returning the print head to the start of the line (carriage return) and advancing the paper (line feed), and early operating systems encoded both actions as separate characters, \r\n. Unix simplified this to a single line feed character standing in for both actions, which is why Linux and modern macOS use LF alone, while Windows kept the original two-character sequence for backward compatibility with early DOS and print hardware. Classic Mac OS, before OS X, went the other direction and used just the carriage return alone, which is why old Mac-era files occasionally show up with lone CR line endings that neither Windows nor Unix tooling expects by default.
A shebang line is a classic place this breaks something
A shell script's first line, #!/bin/bash, tells the operating system which interpreter to run the file with, but if that file was edited or saved with Windows line endings, the line actually reads #!/bin/bash\r, with an invisible trailing carriage return the shell interpreter treats as part of the path. That mismatch commonly produces a "bad interpreter" or "command not found" error that looks like a missing program rather than what it actually is, a stray character at the end of the first line. Converting a script to LF before running it on a Unix-like system is a quick, common fix for exactly this class of error.
How the lone-LF and lone-CR counts avoid double-counting CRLF
A naive count of every \n character in a file would also count the line feed half of every CRLF pair, overstating how many "lone" LF line endings actually exist. This tool's detection uses a negative lookbehind for lone LF (a \n not preceded by \r) and a negative lookahead for lone CR (a \r not followed by \n), so a CRLF pair is counted once as CRLF and never double-counted toward either of the other two categories. This is what makes it possible to say a file has genuinely mixed line endings rather than just reporting three overlapping, inflated numbers.
Where mixed line endings quietly cause problems
Git is one of the more common places this surfaces, a repository shared between Windows and Unix-based contributors can end up showing every line of a file as changed in a diff purely because the line-ending style flipped, even when the actual text content is identical, burying the real change in a wall of noise. CSV and other structured data files are another common trouble spot, a parser expecting one consistent line-ending style can misread a file with mixed endings, sometimes merging two rows into one or splitting a single row into two. Normalizing a file's line endings before committing it or feeding it into a strict parser heads off both of these before they become a debugging session.
Frequently Asked Questions
Why does a shell script fail with a "bad interpreter" error after editing on Windows?
Windows-style line endings add an invisible carriage return to the end of the shebang line, so #!/bin/bash actually reads as #!/bin/bash followed by a stray \r character. The shell treats that as part of the interpreter path, producing an error that looks like a missing program. Converting the file to LF line endings fixes it.
Why did classic Mac OS use a different line ending than both Windows and Unix?
Classic Mac OS, before OS X, used a lone carriage return by itself, while Unix used a lone line feed and Windows kept both characters together as CRLF. All three trace back to how early teletype hardware physically handled a new line, as two separate mechanical actions that different systems encoded differently.
How does this tool count lone LF without also counting the LF inside CRLF pairs?
It uses a negative lookbehind to only count a line feed that isn't immediately preceded by a carriage return. A CRLF pair is counted once as CRLF and excluded from the lone-LF count, so the three totals reflect genuinely distinct line-ending types rather than overlapping counts.
Does converting line endings change the file size?
Yes, slightly. CRLF uses one extra byte per line compared to LF, since it's two characters instead of one. The byte-length difference stat shown after conversion reflects that change across the whole text.
Why does Git show every line of a file as changed when nothing looks different?
This usually happens when a file's line-ending style flipped between commits, Windows CRLF to Unix LF or the other way around. Git sees every line as different purely because of the line ending, even though the actual text content is unchanged, burying the real edits in a wall of noise. Normalizing to one consistent style before committing avoids this.