CRLF/LF Line Ending Converter
Convert line endings between CRLF (Windows), LF (Unix/Linux/macOS) and CR (classic Mac) in pasted text or an uploaded file. Detects the input's current line-ending style, including mixed endings, before converting.
Input
Output
Line Ending Stats
| Metric | Value |
|---|---|
| No data yet | |
Guides
Every text file uses one of three line-ending conventions: Windows writes a carriage return plus a line feed (CRLF, \r\n), Unix, Linux and modern macOS write a single line feed (LF, \n), and classic pre-OS-X Mac used a lone carriage return (CR, \r). Mix them — by editing the same file on Windows and Linux, or pasting from an old export — and tools that expect one convention can misbehave: a shell script fails with a cryptic bad interpreter error, a diff shows every line as changed, or a CSV parser splits rows in the wrong place. This tool detects which line-ending style your text actually uses, flags mixed endings, and converts it to whichever style you need.
How to use it
- Paste your text into the input box, or upload a text file — the file's contents load straight into the same field.
- Choose the target format under Convert To: LF, CRLF, or CR.
- The converted text and a line-ending breakdown update automatically as you type.
- Copy or download the result.
What the stats tell you
The Line Ending Stats table reports:
- CRLF, LF, and CR counts — how many of each line-ending sequence were found in the original text. A CRLF pair (
\r\n) is counted once, not as a CR plus an LF, so the numbers reflect actual line endings rather than raw character counts. - Detected style — the dominant convention in your input. If only one style is present, it's named directly (e.g. "LF"). If more than one style appears — a common sign of a file edited across different operating systems — it reads "Mixed" with the styles that were found.
- Converted to — the format the output was converted to, for confirmation.
Why line endings matter
Line-ending mismatches are a recurring source of "works on my machine" bugs:
- Git diffs can show whole files as changed when only the line endings differ.
- Shell scripts saved with CRLF endings fail to run on Linux/macOS because the shell reads the trailing
\ras part of the command. - Config and CSV parsers that split strictly on
\nleave a stray\rat the end of every field when fed CRLF input.
Converting to a single, consistent line ending before committing or deploying a file avoids all of these.
Which format should I use?
Use LF for anything destined for Linux, macOS, or a Git repository (most .gitattributes setups normalize to LF). Use CRLF for files that specifically need to open correctly in older Windows-only tooling (like Notepad, before Windows 10) or Windows batch scripts. CR is only relevant for legacy classic Mac OS (pre-2001) files — you're unlikely to need it unless you're working with an old archive.
Privacy
Everything runs entirely in your browser. Your text and any uploaded file never leave your device.
Use it from code
From 3 credits per callREST API
curl -X POST https://api.iotools.cloud/v1/tool/crlf-lf-line-ending-converter \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"originalText": "First line with LF ending\nSecond line with CRLF …",
"convertTo": "lf"
}'Swap in your own key from your account. The tool's fields are the body — no wrapper.
Ask an AI agent
Use the IOTools `crlf-lf-line-ending-converter` tool (CRLF/LF Line Ending Converter) on this input:
YOUR_INPUT_HEREPaste this at any agent connected to the IOTools MCP server, then add your input.