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 to LF Line Break Converter
Quick Answer: The CRLF↔LF Line Break Converter detects line ending conventions in your text or code and converts between Windows CRLF (\r\n), Unix/macOS LF (\n), and legacy Mac CR (\r). Preserves file integrity with instant clipboard paste detection.
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.
Detection reads the clipboard, because a textarea quietly rewrites what you paste
The HTML specification dictates that a textarea value is its raw contents with newlines normalized to LF, so by the time pasted text can be read back out of the form control, every carriage return plus line feed in it has already been silently rewritten to a bare line feed. A detector that reads the field the ordinary way therefore reports "Consistent LF" for absolutely everything, including a Windows file that is CRLF from top to bottom. This tool reads the original text directly out of the paste event, where the clipboard payload still carries the real line endings, and detects from that. The stored clipboard text is discarded the moment you edit the box by hand, since manual keystrokes in a browser produce real LF.
Typing can only produce LF, so typed text is genuinely Unix-style
Pressing Enter inside a textarea inserts a line feed and nothing else, so there is no way to type a carriage return into this box at all. If you type your text rather than pasting it, a verdict of "Consistent LF" is the correct answer: what you typed really is LF-only. The CRLF and CR counts are there for pasted content, which is where a mixed or Windows-style file actually comes from.
Why line endings diverged historically
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 roller (line feed). 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 teleprinters. Classic Mac OS, before OS X, used just the carriage return alone.
Shebang lines and interpreter errors
A shell script first line, #!/bin/bash, tells the operating system which interpreter to run the file with. If that file was edited or saved with Windows line endings, the line actually reads with an invisible trailing carriage return that the shell interpreter treats as part of the path. That mismatch produces a "bad interpreter" or "command not found" error that looks like a missing program. Converting a script to LF before running it on a Unix-like system resolves this error immediately.
How lone LF and lone CR avoid double-counting CRLF
A naive count of every newline 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 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 determine whether a file has genuinely mixed line endings.
Where mixed line endings cause problems in production
Git repositories shared between Windows and Unix contributors can show every line of a file as modified in a diff purely because the line-ending style flipped, burying real code changes in noise. CSV and structured data parsers can also misread files with mixed endings, sometimes merging rows or failing imports. Normalizing line endings before committing or processing ensures consistency across all environments.
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 carriage return 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 is not 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 is 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 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.
Can I download the converted file with the exact line endings preserved?
Yes. Clicking the Download .txt button exports a direct plain-text blob preserving the exact binary bytes (either CRLF or LF) without interference from operating system clipboard alterations.
What is the difference between CRLF and LF line breaks?
CRLF represents Carriage Return (\r) followed by Line Feed (\n), typical of DOS and Windows operating systems. LF represents only Line Feed (\n), standard across Unix, Linux, and macOS.
How does Git autocrlf setting interact with line breaks?
Git core.autocrlf configuration converts LF to CRLF upon checking out code on Windows and converts CRLF to LF upon commit. Inconsistent settings across team members frequently cause spurious line-ending diffs.
Can stray CR characters break Docker container builds?
Yes. When building Linux Docker containers from Windows hosts, shell scripts containing CRLF line endings fail during execution with 'no such file or directory' errors because the Linux kernel cannot parse '\r' in the shebang header.
Is my source code or file data uploaded to a server?
No. Conversion and byte calculations occur entirely in client-side memory using JavaScript. None of your source files or scripts are transmitted to external servers.