ALL DEVELOPER TOOLS56
Line Ending Converter
CRLF to LF Converter — Fix Mixed Line Endings
Detect what a text file actually uses, mixed endings included, then rewrite every break as CRLF, LF or CR.
About Line Ending Converter
Line endings are invisible until they are not: Git reports every line of a file as changed when you edited one, and a shell script dies on its first line with a carriage return the shell tried to run as part of a command. The reason is rarely that a file uses the wrong ending. It is that the file uses more than one. So this page counts before it converts. Drop a file and it reports CRLF, LF and CR separately, marks the file as mixed when more than one kind is present, and says how many breaks will change against how many are already what you asked for. A carriage return followed by a line feed is counted once, as one CRLF, so a Windows file is never mis-reported as mixed. It also finds a UTF-8 byte-order mark and leaves it alone until you tick the box. Everything that is not a line ending is copied through, which is why the byte figure adds up exactly. One limit worth knowing: pasting cannot detect anything, because the browser normalises a textarea's value to LF before this page sees it. The file arm is the one that tells you the truth.
Questions
Git says every line changed and I only edited one.
Your editor rewrote the whole file's line endings on save. Git compares bytes, and a line that ended in CRLF and now ends in LF is a changed line even though nothing you can see is different. Drop the file here and the counts tell you which way it went: a file showing all LF that your colleague's diff shows as CRLF is the giveaway. Convert to whatever the repository already uses, commit that as its own change, and then set core.autocrlf or a .gitattributes rule so it stops happening. This page fixes the file; only Git config stops the recurrence.
My shell script fails with '\r: command not found'.
The script has Windows line endings. The shell reads a line up to the LF, which leaves the carriage return attached to the end of the last word, so it looks for a command whose name ends in an invisible control character. The same thing shows up as a bad interpreter error when the shebang line is affected. Drop the .sh file here, convert to LF, and re-download. The counts will confirm what it had. Nothing else in the file changes, so a script that was working apart from this keeps working.
I pasted my file in and it says LF, but my editor says CRLF.
The paste arm cannot detect line endings, and that is the browser's doing rather than a bug here. The HTML specification requires a textarea to normalise every line ending in its value to LF, so by the time this page can read what you pasted, the carriage returns are already gone. There is a warning on screen saying so whenever you switch to Paste. Use the File arm for detection — it reads the raw bytes. Paste is still the right arm for the opposite job: producing CRLF or CR output from text you are composing in the box.
What is the byte-order mark, and should I take it off?
It is three bytes, EF BB BF, that some Windows tools write at the start of a UTF-8 file to say the file is UTF-8. It is invisible in most editors and legal but discouraged in UTF-8. Take it off when it is causing trouble: a shell script whose first line is a shebang will not run with a mark in front of it, a CSV's first column header reads with a stray character glued to it, and JSON.parse rejects the file outright. Leave it when a Windows tool downstream expects it. The page reports whether one was there and removes it only if you tick the box.
It will not accept my .js or .py file.
The picker takes .txt, .csv, .log, .md and .sh, which covers the files people most often hit this problem with but is not the whole world of text. Rename a copy to .txt, convert it, and rename it back — the contents are untouched by the round trip. Two things it genuinely cannot do: a UTF-16 file is refused rather than converted, because rewriting it as UTF-8 would change every byte instead of only the line endings; and a file that is not valid UTF-8 is refused for the same reason, with a pointer to the charset converter.
Is my file uploaded to a server?
No. Transmute processes everything locally in your browser using JavaScript and WebAssembly. Your files never leave your device — there is no server, no upload, no cloud processing.