100% Private & Secure
All conversion happens entirely in your browser using JavaScript. Your files never leave your device. Zero server-side processing for the browser-based converter.
LF vs CRLF: The Silent Source of Cross-Platform File Corruption
Every developer has encountered it at least once: you write a shell script on macOS, transfer it to a Windows server, and suddenly the system refuses to execute it. Or you open a configuration file in Notepad and find every line smashed onto a single row. The culprit is almost always invisible — a two-character discrepancy in how different operating systems have historically decided to represent "end of line."
Understanding the difference between LF (Line Feed) and CRLF (Carriage Return + Line Feed) is not merely academic trivia. It is a practical skill that can save hours of debugging, prevent deployment failures, and ensure that your code, configuration files, and data pipelines behave consistently across every environment they touch.
The Historical Roots of the LF vs CRLF Split
The story begins in the mechanical era of computing. Teletype machines and early line printers required two distinct control characters to advance to the beginning of a new line. The Carriage Return (CR, \r, ASCII 13) moved the print head back to column one, and the Line Feed (LF, \n, ASCII 10) advanced the paper one row. Together — CR followed by LF — they produced the effect of a new line.
When operating systems arrived, each made its own choice. CP/M and later MS-DOS adopted the two-character CRLF sequence (\r\n) because it mirrored the physical behaviour of the hardware they targeted. Unix, in contrast, made the pragmatic decision to use only LF (\n) — a single character that was sufficient to imply both operations on a software-rendered display. Apple's original Mac OS used a lone CR (\r) until macOS X adopted the Unix convention.
The result is that the modern world operates with two dominant conventions: CRLF on Windows and LF on Unix, Linux, and macOS. These conventions are deeply embedded in file formats, network protocols, and developer tooling.
Where the Difference Actually Matters
For casual use, the gap is invisible. Modern text editors like VS Code, Sublime Text, and Notepad++ silently handle both formats. But move beyond the editor, and line-ending mismatches become a serious operational concern:
- Shell Scripts on Windows Servers: A Bash script created on Linux with LF endings will fail to execute under WSL or Cygwin on certain Windows configurations. The interpreter may parse the
\ras part of variable names or command tokens, producing cryptic errors likecommand not found: $'\r'. - Version Control Systems: Git's autocrlf and eol settings exist specifically because CRLF-injected commits cause spurious diffs. A single mass CRLF introduction can show every line of a file as modified, making code reviews useless and bisect operations unreliable.
- CSV and Data Files: Data pipelines processing CSVs may interpret
\r\nas two tokens or produce field-parsing errors if the consuming parser only expects LF. This is a common source of silent data corruption in ETL workflows. - Email and Network Protocols: SMTP, HTTP/1.1 headers, and FTP in ASCII mode all mandate CRLF line endings by RFC specification. Sending a message body with bare LF endings can cause delivery failures or garbled headers on strict mail servers.
- Legacy Windows Applications: Classic Notepad, many Windows-native INI parsers, and old batch scripting engines require CRLF. Feeding them a LF-only file results in the infamous single-line display or parsing breakdown.
- Embedded Systems and Serial Protocols: Many microcontroller communications over UART and serial connections strictly expect CRLF as a command terminator, making the conversion essential for hardware-software integration.
How LF to CRLF Conversion Works Under the Hood
The conversion process is conceptually simple but requires care to be lossless and idempotent. A naïve replacement of every \n with \r\n will double-convert any CRLF sequences that already exist — transforming \r\n into \r\r\n. A correct algorithm always normalizes first:
// Step 1: Normalize all CRLF to LF (avoid double-conversion)
content = content.replace(/\r\n/g, '\n');
// Step 2: Convert all remaining bare LF to CRLF
content = content.replace(/\n/g, '\r\n');
content = content.replace(/\r\n/g, '\n');
// Step 2: Convert all remaining bare LF to CRLF
content = content.replace(/\n/g, '\r\n');
This two-pass approach is robust against mixed-ending files, which are common when files are edited by multiple developers across platforms. Our converter implements exactly this logic — ensuring every output file has consistent, clean CRLF endings without any rogue \r\r\n sequences.
Managing Line Endings in Git
For development teams, the most sustainable solution is enforcing line endings at the repository level using a .gitattributes file. This eliminates the need for manual conversion in most daily workflows:
# .gitattributes
* text=auto # Auto-detect text files
*.sh text eol=lf # Shell scripts always LF
*.bat text eol=crlf # Batch files always CRLF
*.ps1 text eol=crlf # PowerShell always CRLF
*.csv text eol=crlf # CSV for Windows tools
* text=auto # Auto-detect text files
*.sh text eol=lf # Shell scripts always LF
*.bat text eol=crlf # Batch files always CRLF
*.ps1 text eol=crlf # PowerShell always CRLF
*.csv text eol=crlf # CSV for Windows tools
Command-Line Alternatives
For power users who prefer the terminal, several reliable tools exist. On Linux and macOS, dos2unix and unix2dos are the canonical utilities. On any system with sed available, a one-liner handles the conversion:
# Using unix2dos (install via apt/brew)
unix2dos input.txt
# Using sed (portable, any Unix)
sed -i 's/$/\r/' input.txt
# Using PowerShell on Windows
$content = Get-Content -Raw input.txt
$content -replace "(?<!\r)\n", "`r`n" | Set-Content output.txt
unix2dos input.txt
# Using sed (portable, any Unix)
sed -i 's/$/\r/' input.txt
# Using PowerShell on Windows
$content = Get-Content -Raw input.txt
$content -replace "(?<!\r)\n", "`r`n" | Set-Content output.txt
When to Use LF vs CRLF in 2025
The modern consensus has largely settled around LF as the default for source code — driven by Git's Unix heritage, the dominance of Linux servers, and the widespread adoption of the .editorconfig standard. However, specific scenarios still demand CRLF:
- Files intended exclusively for consumption by Windows-native programs
- Emails, SMTP payloads, and MIME boundaries
- HTTP protocol messages when built manually
- INI configuration files for Windows Registry tools
- CSV exports intended for Excel or Windows-based data tools
- Legacy system integrations that predate Unicode normalization
Our LF to CRLF converter bridges these worlds — giving you precise, instant control over line endings so you can meet any platform's requirements without touching a terminal.