Line Ending Converter

Convert text between LF (Unix), CRLF (Windows), and CR (Classic Mac) line endings. Detects mixed endings and works entirely in your browser.

Samples:
Convert to
Options
Detected in input
CRLF (\r\n) 3
LF (\n) 0
CR (\r) 0
Dominant: crlf
Input
108 chars · 3 line breaks
Output (\n)

Why Line Endings Matter

  • Git diffs explode when CRLF and LF mix
  • Shell scripts fail with ^M errors
  • Build tools like Make and Bash require LF
  • Windows tools may corrupt LF-only files
  • Cross-team work on macOS, Linux, and Windows

What This Tool Does

  • Convert any text to LF, CRLF, or CR
  • Replaces dos2unix and unix2dos for quick edits
  • Counts each ending type in your input
  • Flags mixed line-ending files
  • Optional trim of trailing whitespace
  • Optional final-newline enforcement

Privacy & Speed

  • 100% client-side — nothing is uploaded
  • Safe for proprietary code, configs, and logs
  • No sign-up, no rate limits, no API keys
  • Conversion is instant as you type
  • Free and open to use

About the Line Ending Converter

The Line Ending Converter is a free online tool that normalizes text to a specific end-of-line (EOL) sequence. It supports the three line-break conventions that exist in modern computing: LF (\n) used by Unix, Linux, and modern macOS; CRLF (\r\n) used by Windows and DOS; and CR (\r) used by Classic Mac OS up to version 9.

Mixed line endings are a common source of broken builds, noisy Git diffs, and cryptic ^M characters in shell scripts. This tool detects every line-ending type present in your text, reports the counts, and rewrites the file using whichever ending you choose — entirely in your browser, with no upload, no server, and no installation.

How to Use the Line Ending Converter

  1. Load your text using one of three methods: paste into the input box, drag and drop a file onto the input area, or click Upload to pick a file. Files are read with their original bytes intact — pasting goes through the browser textarea, which normalizes all line endings to LF.
  2. Choose your target line ending in the Convert to panel: LF for Unix, CRLF for Windows, or CR for Classic Mac OS.
  3. Optionally enable Trim trailing whitespace to clean up tabs and spaces at the end of each line.
  4. Optionally enable Ensure file ends with a newline — POSIX-compliant tools often expect this.
  5. Watch the Detected in input panel — it shows how many CRLF, LF, and CR sequences were found and warns if they are mixed.
  6. Toggle the output between Rendered and Show invisibles. The invisibles view tags every line break with a colored \r\n, \n, or \r badge so you can verify the conversion at a glance.
  7. Conversion runs automatically as inputs and options change. Use Copy to grab the result, Download to save it as a .txt file, or Swap to feed the output back into the input for a second pass.

Common Use Cases

  • Fix shell scripts — convert .sh, .bash, or Makefile files from CRLF to LF so they run on Linux and macOS without /bin/bash^M: bad interpreter errors.
  • Clean Git diffs — normalize a file before committing so the diff isn't dominated by line-ending noise from a teammate on a different OS.
  • Replace dos2unix / unix2dos — get the same conversion from anywhere with a browser, no install, no admin rights.
  • Prepare CSV and JSON files — many parsers handle line endings inconsistently; pick LF for cross-platform safety or CRLF if you're targeting Excel on Windows.
  • Strip trailing whitespace — combine with the convert step to enforce one consistent style across an entire file in a single click.
  • Convert legacy logs — old log dumps, exported FTP transfers, or files from Classic Mac systems often arrive with CR-only endings that modern editors mangle.
  • Audit suspicious files — paste a file and read the line-ending counts to confirm whether it really uses the convention your build tool expects.

Frequently Asked Questions

What's the difference between LF, CRLF, and CR?

LF (Line Feed, \n, byte 0x0A) is used by Unix, Linux, and macOS since OS X. CRLF (Carriage Return + Line Feed, \r\n, bytes 0x0D 0x0A) is used by Windows and DOS, inherited from teleprinters where the carriage had to physically return before the line could feed. CR (\r, byte 0x0D) was used by Classic Mac OS up to version 9 and is now mostly historical.

Is my text uploaded anywhere?

No. Conversion runs entirely in your browser using JavaScript. Even when you upload or drop a file, it is read locally with the FileReader API and never leaves your device — safe for proprietary source code, internal configs, or any sensitive data.

Why do pasted text and uploaded files behave differently?

HTML <textarea> elements normalize every \r\n and \r to \n when reading their value — that's part of the HTML spec. So pasted text always arrives as LF-only, and the "Detected in input" stats reflect that. Files loaded via Upload or drag-and-drop are read with FileReader, which preserves the original bytes. If you need to detect the real line endings of a file, drop the file rather than pasting its contents.

Why does select+copy from the output give the same result as the input?

Same reason as above — selecting text inside a <textarea> and copying with Cmd+C goes through the browser's normalized DOM value, so the OS clipboard always receives LF. To get the actual converted bytes, click the tool's Copy button (which uses the Clipboard API on the raw JS string) or click Download to save a file. You can verify with pbpaste | xxd on macOS or xxd converted.txt on Linux.

What does the "Show invisibles" view do?

It renders the output as a code block where each line break is replaced by a small colored badge — pink for \r\n, blue for \n, amber for \r — followed by an actual line break. This makes it instantly obvious which line ending sits at the end of every line, which a normal textarea cannot show.

How do I fix the ^M characters in my shell script?

Paste the script into the input, choose LF as the target, and copy the result back. The ^M you see in vim or cat -A is the visible representation of a CR character — switching to LF strips them.

Which line ending should I use for source code?

Most modern projects standardize on LF, including those edited on Windows, because Git, Linux build servers, and language runtimes all prefer it. Configure your editor to save with LF, or use a .gitattributes file with * text=auto eol=lf to enforce it.

What does "mixed line endings detected" mean?

It means your input contains more than one type of line break — for example, some lines end in CRLF and others end in LF. This is a common cause of broken parsers and noisy Git diffs. Running the conversion will normalize every line to your chosen ending.

Does the converter handle Unicode line separators?

No. Only the three traditional ASCII-based line endings (CR, LF, CRLF) are recognized. Unicode characters such as U+2028 (Line Separator) and U+2029 (Paragraph Separator) are preserved as-is and not treated as line breaks.

Will it change the encoding of my file?

No. The text is read and written as-is in your browser; only the byte sequences for line endings are rewritten. Other characters, including UTF-8 multibyte sequences, are not modified.

Why would I add a trailing newline?

POSIX defines a text line as a sequence of characters terminated by a newline, so many Unix tools (wc, git diff, cat) expect a final newline. Files without one are technically not valid text files and may produce warnings.

Can I use this for commercial work?

Yes. The tool is free for any purpose — commercial, private, educational, or personal. Since nothing leaves your device, there are no data-privacy concerns for internal business use.