Line Ending Converter
Paste text or drop files to see which line endings they use, then convert them to LF, CRLF or CR in one click. Files are converted byte by byte in your browser, so UTF-8 text is never damaged and nothing is uploaded.
Browsers turn every line break you type into LF. Line endings in pasted text are kept exactly; to check a file byte for byte, use the Files tab.
How to use the Line Ending Converter
- Paste text or open the Files tab and drop one or more files (code, CSV, config, text).
- Check the detected line endings. The counters show how many CRLF, LF and CR breaks were found and warn when they are mixed.
- Choose the target: LF for Linux, macOS and Git repositories, CRLF for Windows tools, CR only for very old Mac software.
- Pick the extras you want: trim trailing whitespace, ensure a final newline, and keep, remove or add a BOM.
- Press Convert line endings, then copy the text or download each file with its original name (or all files as a ZIP).
Line endings at a glance
| Name | Bytes | Escape | Used by |
|---|---|---|---|
| LF (line feed) | 0A | \n | Linux, macOS (OS X and later), Android, most programming languages, Git repositories |
| CRLF (carriage return + line feed) | 0D 0A | \r\n | Windows, MS-DOS, HTTP headers, SMTP email, many network protocols, CSV files from Excel |
| CR (carriage return) | 0D | \r | Classic Mac OS 9 and earlier, some old printers and devices |
The names come from typewriters and teleprinters: a carriage return moved the print head back to the start of the line and a line feed advanced the paper. Windows kept both characters, Unix kept only the line feed, and classic Mac OS kept only the carriage return.
Where the wrong line ending causes trouble
- Shell scripts: a script saved with CRLF fails with
/bin/bash^M: bad interpreteror$'\r': command not found. Convert it to LF. - Git diffs: when an editor changes every ending, a diff shows every line as modified even though no content changed.
- Docker and CI: entrypoint scripts and config files copied from Windows into Linux containers need LF.
- Windows tools: old versions of Notepad and some batch files expect CRLF and may show LF files as one long line.
- Protocols: HTTP/1.1 headers and SMTP email lines must end with CRLF by specification (RFC 9112 and RFC 5321).
Fix line endings for good in Git
Converting a file once helps, but a .gitattributes file at the root of the repository stops the problem from coming back. A common setup stores text with LF and lets Windows-only files keep CRLF:
* text=auto eol=lf
*.bat text eol=crlf
*.cmd text eol=crlf
*.png binaryAfter adding the file, run git add --renormalize . and commit to rewrite existing files. On the command line you can also use dos2unix file.txt and unix2dos file.txt, or sed -i 's/\r$//' file.txt to strip carriage returns.
How to see line endings in your editor
- VS Code: the status bar shows LF or CRLF; click it to change the current file. The
files.eolsetting controls new files. - Notepad++: View › Show Symbol › Show End of Line, and Edit › EOL Conversion to convert.
- Vim:
:set ff?shows the format;:set ff=unixthen:wconverts to LF. - Terminal:
file name.txtreports "with CRLF line terminators", andcat -Ashows CR as^M.
Frequently asked questions
What is the difference between CRLF and LF?
Both mark the end of a line. LF is a single line feed byte (0x0A) used by Linux, macOS and most programming tools. CRLF is a carriage return followed by a line feed (0x0D 0x0A) and is the Windows convention. CR alone (0x0D) was used by classic Mac OS before OS X.
Why does Git warn that LF will be replaced by CRLF?
Git can normalise line endings when you commit or check out files, controlled by core.autocrlf and .gitattributes. The warning means a file in your working copy uses a different ending than Git will store. Converting the file to LF before committing, or adding a rule such as * text=auto eol=lf to .gitattributes, makes the warning go away.
Will converting damage UTF-8 or special characters?
No. The bytes 0x0D and 0x0A never appear inside a multi-byte UTF-8 character, so the tool changes only the line-break bytes (and trailing spaces or tabs if you ask it to). Every other byte is copied exactly. UTF-16 files with a BOM are converted per 16-bit character for the same reason.
What are mixed line endings?
A file has mixed endings when some lines end with CRLF and others with LF or CR, which often happens after copying code between Windows and Unix editors. Mixed endings can break diffs, shell scripts and some parsers. Converting the whole file to one style fixes it.
Why can a shell script fail with '\r: command not found'?
The script was saved with Windows CRLF endings, so Bash sees an extra carriage return at the end of every line. Converting the script to LF fixes the error.
What does the BOM option do?
A byte order mark is an invisible marker at the start of a file. Some Windows programs add it to UTF-8 files, while many Unix tools and PHP or shell scripts do not expect it. Keep leaves it unchanged, Remove deletes it and Add puts a UTF-8 BOM at the start of UTF-8 text.
Are my files uploaded?
No. Files are read and converted with JavaScript in your browser and the results are saved straight from your device. Nothing is sent to a server.