Paste text or drop a file to check its line endings and BOM, then convert to LF, CRLF, or CR and copy or download the result.
This tool runs entirely in your browser. What you enter is never sent anywhere.Your input is never sent anywhere.
DetailsPaste Text or Upload a File
Drag and drop a file to load it
Detected line ending
No line breaks (single line)
BOM
None
Lines
0
Characters
0
Convert line endings to
Byte order mark (BOM)
Converted Output
Lines
0
BOM
No
Size
0 B
TIP
Use LF with no BOM for source code, JSON, and files stored in Git. Use CRLF for files meant for Windows-only tools such as batch files.
CRLF, LF, and CR: What the Converter Changes
A line ending is the invisible character, or pair of characters, that ends each line of a text file. Windows uses CRLF (\r\n), Linux and modern macOS use LF (\n), and Classic Mac OS used CR (\r). A file saved on one system can misbehave on another: scripts fail, diffs get noisy, and parsers stop at the first character.
This tool detects which line endings your text uses, counts each type, and converts every line break to LF, CRLF, or CR. It can also remove, keep, or add the UTF-8 byte order mark (BOM), so you can strip a BOM that breaks a JSON parser or add one that Excel needs.
Paste text or drop a file. The conversion runs in your browser, so the contents are not sent to a server.
When to Change Line Endings or the BOM
A script fails after you copy it to Linux
A shell script saved with CRLF carries a hidden \r at the end of each line, and it can fail with errors such as “bad interpreter” or “required file not found.” Convert it to LF before you run or deploy it.
Git diffs show every line as changed
When teammates on Windows and macOS save the same file, the whole file can show as changed in a diff, and Git may warn that “LF will be replaced by CRLF.” Normalize the file to one line ending, then commit.
JSON or YAML fails on the first character
A UTF-8 BOM at the start of a JSON file makes JSON.parse in JavaScript and json.load in Python throw an error. Remove the BOM and the file parses normally.
A CSV looks garbled in Excel
Excel can misread a UTF-8 CSV that has no BOM and show accented or non-Latin characters as strange symbols. Add the BOM, download the file, and open it again.
How to Convert CRLF to LF, LF to CRLF, or Remove a BOM
- Paste text into the box, or drop a file onto it (or press Choose file).
- Check the detected line ending, BOM status, line count, and character count. A breakdown appears when the text contains line breaks.
- Under Convert line endings to, pick LF, CRLF, or CR. Under Byte order mark (BOM), pick Remove, Keep as is, or Add.
- Review the output (turn on Show line endings to see CRLF, LF, and CR labels), then press Copy result or Download.
Note: Everything runs in your browser. The text and files you use are not sent to a server.
Before You Convert: Limits and Tips
- Files are read as UTF-8 and saved as UTF-8. Other encodings, such as Windows-1252 or UTF-16, can show garbled characters, and the garbled characters are what get saved.
- Only text files are supported. Images, archives, and executables are not.
- Typing or editing inside the input box converts its line breaks to LF, because the browser reports them that way. Paste into an empty box (or select all first) or upload a file to keep the original line endings for detection.
- Copy result puts the text on your clipboard, but some apps normalize line endings or drop the BOM when you paste. Use Download when the exact bytes matter.
- The output preview shows the first 500 lines. Copy and Download always use the whole text.
- Very large files depend on your browser’s memory and may take a while to process.
Windows, Unix, and Classic Mac Line Endings
How each line ending is written and stored, and where you are likely to meet it.
| Name | Escape | Hex bytes | Where it is used |
|---|---|---|---|
| LF | \n | 0A | Linux, macOS, and other Unix-like systems; the usual choice for source code in Git |
| CRLF | \r\n | 0D 0A | Windows text files and batch files; also used by protocols such as HTTP and SMTP |
| CR | \r | 0D | Classic Mac OS (before OS X); rarely used today |
Not sure which to choose? Use LF for code in a Git repository and for files that run on Linux or macOS. Use CRLF for files meant for Windows-only tools, such as batch files.
How Line Endings and BOMs Break Scripts, Git, and CSV Files
Both are invisible in most editors, which is why they are easy to miss.
Shell scripts: Windows line endings on Linux
A script saved with CRLF has a hidden \r at the end of every line, including the #! line. Linux then looks for an interpreter whose name ends in a carriage return, and the script stops with an error such as “bad interpreter” or “required file not found,” depending on your shell. Converting the script to LF removes the stray character.
Git: line endings in diffs and the “LF will be replaced by CRLF” warning
Git compares lines including their endings, so a file re-saved with a different line ending can appear fully changed in a diff. On Windows, Git may also print LF will be replaced by CRLF the next time Git touches it when core.autocrlf is on. A .gitattributes rule such as * text=auto eol=lf keeps a repository consistent, and this tool fixes individual files you already have.
BOM: when to remove it and when to add it
The BOM is the character U+FEFF at the start of a file, stored as EF BB BF in UTF-8. UTF-8 does not need it. Remove it from JSON, YAML, shell scripts, and other files read by programs: JSON.parse in JavaScript and json.load in Python both reject a JSON file that starts with a BOM, and a BOM in front of #! breaks the first line of a shell script. Add it when Excel needs to recognize a UTF-8 CSV that contains accented or non-Latin characters.
Suggested settings by file type
Source code, JSON, YAML, and shell scripts in Git: LF, BOM removed
Windows batch files (.bat, .cmd): CRLF, BOM removed
CSV that opens in Excel with accented or non-Latin text: BOM added; keep the line ending your importer expects
Match the setting to the system that will read the file, and most line ending and BOM errors do not happen.
Error Messages You Might Be Fixing
A shell script fails right after you copy it to Linux
The script was written in a Windows editor and saved with CRLF. Running it prints errors such as “bad interpreter” or “required file not found,” or leaves a stray \r in the output.
💡 See the solution▼
Every line shows as changed in a pull request
The file was re-saved with a different line ending, so Git sees every line as modified and the real edits are hard to find.
💡 See the solution▼
JSON.parse or json.load fails on the first character
The JSON file was exported by a tool that saves UTF-8 with a BOM, and the parser rejects the invisible character at the start.
💡 See the solution▼
A UTF-8 CSV looks garbled in Excel
Accented letters or non-Latin characters appear as strange symbols after you double-click the CSV.
💡 See the solution▼
Line Endings and BOM: Frequently Asked Questions
Q.What is the difference between CRLF, LF, and CR?
A. They are different ways to mark the end of a line in a text file. LF (\n, byte 0A) is the line ending on Linux, macOS, and other Unix-like systems. CRLF (\r\n, bytes 0D 0A) is the standard on Windows. A lone CR (\r, byte 0D) was used by Classic Mac OS and is rare today.
Q.How do I convert CRLF to LF?
A. Paste your text or drop a file, leave the target set to LF, and press Copy result or Download. Every CRLF and every lone CR in the text becomes LF. On your own machine you can get the same result with dos2unix, with sed -i 's/\r$//' file on GNU sed, or by clicking CRLF in the VS Code status bar and choosing LF.
Q.How do I convert LF to CRLF?
A. Select CRLF as the target. Every LF and every lone CR becomes CRLF, and lines that already end in CRLF are not doubled. The unix2dos command does the same thing in a terminal.
Q.What happens to a file with mixed line endings?
A. The tool counts CRLF, LF, and CR separately and flags the text as mixed. When you convert, every line break is replaced with the type you picked, so the result uses one type from start to end.
Q.What is a BOM, and should I remove it?
A. A BOM (byte order mark) is the character U+FEFF at the start of a file. In UTF-8 it is stored as the three bytes EF BB BF. UTF-8 has no byte-order ambiguity, so the BOM is optional. Remove it from JSON, shell scripts, and config files, where parsers can fail on it. Add it when a program such as Excel needs it to recognize a UTF-8 CSV.
Q.Is my text or file uploaded anywhere?
A. No. The page reads the file with browser APIs and converts it with JavaScript on your device. The tool does not send the text or the file to a server.
Q.Which files and encodings does it support?
A. Any plain-text file, such as .txt, .csv, .json, .md, .yml, .sh, .html, or source code. Files are read as UTF-8, and the output is always UTF-8. If a file uses another encoding, such as Windows-1252 or UTF-16, characters can look garbled and the garbled characters are what get saved. Binary files such as images and executables are not supported.
Your feedback
makes this tool better.
Tell us which features you'd like, what should be fixed, or which new tool you'd like to see. An engineer reads every submission and uses it to guide development.