Line Ending Converter
Normalize line endings to CRLF / LF / CR with automatic detection and per-style counts — a lifesaver for cross-platform script errors.
>_ USAGE GUIDE
Paste text in, and the tool auto-detects the current line-ending style and reports the count of each type, then normalizes everything to CRLF (Windows) / LF (Unix/macOS) / CR (legacy Mac) in one click — copy the output and overwrite the file to save.
Line endings are the invisible characters at the end of each line: Windows uses carriage return plus line feed (\r\n, CRLF); Unix/Linux and modern macOS use only line feed (\n, LF); ancient Mac used carriage return (\r, CR). Files produced on different systems mix these characters, which triggers script errors, whole-file git diffs, and config parsing failures.
- Paste the text: content with mixed or uncertain line endings
- Read the detection: see which style is current and how many of each type are present
- Choose a target: CRLF for Windows workflows, LF for Unix/macOS and most Git repos, CR only for legacy needs
- Normalize: convert everything to one style and copy the result back
Conversion touches only the end-of-line markers and never alters the text; processing happens locally with zero uploads.
>_ FAQ
Q1 · What is the difference between CRLF and LF?
CRLF is two characters — carriage return \r (CR) plus line feed \n (LF) — the Windows convention; LF is a single line feed \n, the Unix/Linux and modern macOS convention. They are invisible but really present in files, and mixing them causes all kinds of "line ending" problems. Most modern tools handle either, but a file should stay internally consistent.
Q2 · Why does a script written on Windows fail on Linux?
Windows creates CRLF line endings by default; a Linux interpreter (especially sh, or a script with a shebang like .py) treats the trailing \r as part of the command, producing "command not found" or strange syntax errors. Normalizing the file to LF usually fixes it immediately.
Q3 · Should I normalize to CRLF or LF?
It depends on where the file runs or is committed: for Linux/macOS or Git repositories, normalize to LF (Git recommends LF and can auto-convert via core.autocrlf); for Windows-only tools like Notepad, use CRLF. Modern editors and Git mostly handle the conversion, but committing files as LF keeps cross-platform diffs clean.
Q4 · Why does git show the whole file changed when I only edited a few lines?
The classic cause is a global line-ending change — some save or tool converted the whole file from CRLF to LF (or the reverse), so Git sees every line as modified. First normalize the file to the repo's convention (with .gitattributes or core.autocrlf), then make your real edits, and the spurious whole-file diff disappears.
Q5 · What if the text mixes several line-ending styles?
Let the tool auto-detect and show the counts of each style to confirm it is genuinely mixed, then pick a target and normalize in one click. With everything unified, the file opens, commits, and parses cleanly across platforms.