Line Ending Converter

Detect and convert line endings between CRLF (Windows), LF (Unix/Mac), and CR (old Mac).

Convert to:

Input

Detected format: NoneLine endings: 0

Output

Characters: 0

What are line endings?

Different operating systems use different characters to mark the end of a line. Windows uses CRLF (Carriage Return + Line Feed, \r\n), Unix/Linux/macOS use LF (\n), and classic Mac OS (pre-OS X) used CR (\r). Mismatched line endings can cause issues with text editors, version control (git), shell scripts, and configuration files. This tool detects the current format and converts to your chosen target.

Built and maintained by Meet Shah · Last updated 5 August 2026

What this tool is used for

Fixing a script that fails on Linux because it was saved with Windows line endings.
Normalising a file before committing it so the diff is not the entire file.
Converting a data file for a parser that only accepts one convention.
Identifying which convention a mystery file actually uses.
Cleaning a file that has picked up a mixture of both.

Frequently Asked Questions

Why do three different line endings exist?: They inherit from teleprinters, where CR returned the carriage and LF advanced the paper. Windows kept both (\r\n), Unix used LF alone, and classic Mac OS used CR alone — a split that has never been resolved.
What breaks when the endings are wrong?: Shell scripts fail with confusing errors because the shebang line ends in an invisible \r; git shows every line as changed; and some parsers include the \r in the last field's value, so a comparison against "value" fails.
What does git's autocrlf do?: It converts on checkout and commit — true on Windows, input on Unix. Misconfiguration is why a repository can show whole-file diffs with no real change. A .gitattributes file with explicit rules is more reliable than the global setting.
Should a file end with a newline?: Yes — POSIX defines a line as ending with one, which is why tools warn about "no newline at end of file". Its absence also makes the last line's diff noisy when anything is appended.
What about the old Mac CR ending?: Obsolete since Mac OS X adopted LF in 2001, but it still appears in files from classic Mac software and some legacy exports. A converter that handles only CRLF and LF leaves those files as one enormous line.
How do I tell which endings a file uses?: By looking for the bytes rather than the display — `file` reports it, and most editors show it in the status bar. A file can also mix them, which is the case that breaks tools expecting consistency.
Why does a shell script fail with a strange error on Linux?: Because a CRLF file leaves a carriage return on the shebang line, so the kernel looks for an interpreter whose name ends in an invisible character. The resulting "not found" names a file that plainly exists.

Common errors and gotchas

Overlooking a mixed file, where converting only the wrong ones leaves an inconsistent result.
Converting a binary file, which corrupts any byte that happens to match a line-ending value.
Fighting the version-control setting rather than fixing it, so every checkout reintroduces the problem.
Assuming the invisible characters are visible. A CR at the end of a line shows as nothing in most editors.
Converting a file with an explicit trailing newline convention and losing or adding one.