Text
CRLF ↔ LF Converter
Convert line endings between Windows (CRLF), Unix/macOS (LF), and classic Mac (CR), with mixed-ending detection.
The browser normalizes pasted text to LF itself, so original CRLF/CR cannot be detected here — to analyze or convert a file with real CRLF/CR, use the file upload above.
Windows, Unix/macOS, and the old classic Mac historically use different characters to mark the end of a line — CRLF, LF, and CR respectively. Mixing these styles in one file often causes odd artifacts in diffs or editors. This tool converts line endings to one style and detects mixed ones.
How to use it
- Paste text and the tool automatically detects the current line-ending style, including a mixed one.
- Pick a target format (CRLF, LF, or CR) and the conversion happens instantly.
- If several styles are found in the same file, that's flagged with a separate warning.
Common uses
- Fixing a file where git diff shows every line as changed because of differing line endings, even though the content itself didn't actually change.
- Converting a text file to the format a specific system or script expects (a Unix script, for instance, expects LF).
- Debugging why a file opened in a Windows editor shows the entire text on one line (a sign of plain LF with no CR).
Things to keep in mind
Git can automate this conversion itself through core.autocrlf or .gitattributes — often more convenient than converting files in a repository by hand.
Mixed line endings in one file aren't always visible at a glance, but they can break parsers or scripts that expect one specific style.
Article about this tool: CRLF vs LF: why line ending characters still matter
Frequently asked questions
Why do line endings differ by system?
Windows uses CRLF (\r\n), Unix and macOS use LF (\n) alone, and classic Mac used CR (\r) alone — these different historical conventions cause inconsistencies when a file moves between systems.
Why do I need to upload a file instead of pasting text?
The browser automatically normalizes any text pasted into an input field to LF, so real original CRLF or CR characters become undetectable once pasted — only a direct file upload preserves its actual line endings for analysis or conversion.
When does this kind of issue actually matter?
It matters most with git (noisy diffs caused by line endings), shell scripts that fail with leftover CRLF, and files exchanged between Windows and Unix/macOS systems; the uploaded file is only processed locally in the browser, never sent to a server.
What if a file has mixed CRLF and LF endings?
A file edited across multiple editors or operating systems can contain both styles at once. The conversion needs to be applied to the whole file, not just the visibly "suspicious" lines — otherwise some of the problem endings stay unnoticed.
Can this conversion be automated through git?
Yes, the core.autocrlf setting in git automatically converts line endings on checkout and commit, and .gitattributes lets you explicitly set the ending style for specific file types in a repository.