Line Ending Converter

1. Paste text or drop a file. The status line shows what the input contains, for example "Input: 3 CRLF → LF", and says "(mixed)" when more than one style is present.
2. Pick the target in the Line endings menu in the title bar: LF for Unix, Linux and macOS, CRLF for Windows, or CR for classic Mac OS.
3. Download the converted file with ⌘/Ctrl S. Copying into another editor may re-convert line endings, so download when the exact bytes matter.

Line endings are invisible, so inputs and outputs below are written with escape sequences: \r\n is CRLF, \n is LF and \r is CR.

#A Windows file to Unix

Target LF, the default. Status: "Input: 3 CRLF → LF".

line one\r\nline two\r\nline three\r\n

Result:

line one\nline two\nline three\n

#Mixed line endings

A file edited on different systems can contain all three styles. Every break is normalized, the missing final newline is added, and a notice reports "Input had mixed line endings — all were normalized." Status: "Input: 1 CRLF · 1 LF · 1 CR (mixed) → LF".

alpha\r\nbeta\ngamma\rdelta

Result:

alpha\nbeta\ngamma\ndelta\n

#To CRLF without a final newline

The same mixed input with target CRLF and Ensure final newline off — the last line is left as it was:

alpha\r\nbeta\r\ngamma\r\ndelta

#Trimming trailing whitespace

With Trim trailing whitespace on, spaces and tabs at the end of each line are removed while converting. Input x = 1 \ny = 2\t\n becomes x = 1\ny = 2\n.

• Line endings — the target style: LF (Unix, macOS), CRLF (Windows) or CR (classic Mac). Every existing break, whatever its style, is converted to it.
• Ensure final newline — on by default; adds one line ending at the end of the text if it is missing. POSIX tools and Git expect text files to end with a newline.
• Trim trailing whitespace — removes spaces and tabs at the end of every line, a common source of noisy diffs.

#/bin/bash^M: bad interpreter

A shell script saved with CRLF endings. The kernel reads the interpreter path as /bin/bash\r, which does not exist. Convert the file to LF, and add *.sh text eol=lf to .gitattributes so it stays that way.

#Every line shows as changed in a diff

One side of the diff uses CRLF and the other LF. Convert to the style your repository uses, then commit. Git's core.autocrlf setting or a .gitattributes rule prevents it from happening again.

#"No newline at end of file" in Git

The last line has no line ending. Keep Ensure final newline on to add one.

#A .env or config value has a stray \r

Windows line endings leave an invisible carriage return at the end of each value, so PORT=3000 is read as 3000\r on Linux. Convert the file to LF before deploying.

#The status says "no line breaks"

The input is a single line. Nothing changes except the final newline, if that option is on.

#What is the difference between CRLF and LF?

Both mark the end of a line. LF is a single line-feed character (\n) used by Unix, Linux and macOS. CRLF is a carriage return followed by a line feed (\r\n), inherited from typewriters and teleprinters, and used by Windows and many internet protocols. Most editors read both, but shells, parsers and diffs treat them differently.

#How do I convert CRLF to LF without dos2unix?

Paste or drop the file here with the target set to LF, then download it. On the command line, sed -i 's/\r$//' file or tr -d '\r' < in > out do the same on Unix systems. In Git, git add --renormalize . applies your .gitattributes rules to files already committed.

#How can I tell which line endings a file uses?

Paste it here; the status line counts each style, for example "Input: 12 CRLF · 3 LF (mixed)". On the command line, file name.txt reports "with CRLF line terminators", and most code editors show the current style in their status bar.

#Should my repository use LF or CRLF?

LF is the usual choice for cross-platform projects, because Unix tools, containers and CI runners expect it, and modern Windows editors handle it. Record the decision in .gitattributes, for example * text=auto eol=lf, so every contributor's checkout converts consistently. Windows-only files such as .bat can be set to CRLF.

#Does the converter change anything besides line endings?

Only if you ask it to. With Trim trailing whitespace off, the only changes are the line endings themselves and, if enabled, one final newline. Tabs, indentation, Unicode characters and encoding are left alone.

#Are my files uploaded?

No. Conversion runs in your browser, inside an isolated frame that blocks network requests; large files are handled in a background worker. Settings are remembered on this device, and file content is not stored unless you turn on "Remember my last input".

Remove invisible characters and extra spaces with the Text Cleaner, or tidy a dotenv file with the .env Formatter. All text tools are listed under Text.