Line Ending Converter (CRLF/LF/CR)

Convert text file line endings between Windows (CRLF), Unix (LF), and old Mac (CR).

Tested tool guide Tested browser tools Checked August 16, 2026

What Line Ending Converter (CRLF/LF/CR) does, with a checked example

Line Ending Converter changes the control-character sequence used at every stored newline in text: Windows CRLF, Unix LF, or classic Mac CR. CRLF combines carriage return and line feed, while the other choices use one of those characters alone. Choose the required destination style and convert the text before copying or saving the result. The usual surprise is that input and output look identical on screen. Those endings are normally rendered alike, so the visible line layout cannot confirm which sequence the result contains.

Worked example

A concrete input and expected output from the current implementation.

Input

alpha
beta

Expected output

alpha
beta

With LF selected, the single CRLF boundary between alpha and beta is replaced by one LF character. The two visible lines remain the same; only their separator changes.

How the result is produced

Target sequences

CRLF consists of carriage return U+000D followed immediately by line feed U+000A. LF is U+000A alone, and CR is U+000D alone. Selecting one of the three targets means representing every supported text boundary with exactly that sequence. In a CRLF-to-LF conversion, each adjacent CR plus LF pair becomes one LF, rather than two separate line breaks.

Logical lines

Changing the boundary representation can change the string's code-point count without changing its logical line count. CRLF uses two code points per boundary, while LF and CR use one. The conversion does not turn visual word wrapping into stored newlines, and it is not a character-set conversion, whitespace cleanup, or paragraph reflow operation.

Good uses

Convert CRLF from a Windows-authored shell script or configuration file to LF before using a Unix-oriented program that exposes carriage returns.
Change LF text to CRLF when a legacy importer or a text-based interchange requirement explicitly expects carriage-return plus line-feed record boundaries.
Translate CR-only text recovered from a classic Mac document into LF or CRLF before passing it to software that does not recognize lone CR.

Limits and checks

A converted preview can look exactly like the source because the three supported endings are invisible and are commonly displayed as the same line break.
Copying converted text through another editor, clipboard path, or formatter can normalize endings again. Verify the final saved file when exact EOL characters matter.
The named targets cover CRLF, LF, and CR. Do not assume the converter also rewrites Unicode NEL U+0085, line separator U+2028, or paragraph separator U+2029.

Common questions

Why does the converted text look unchanged?

CRLF, LF, and CR are invisible control sequences, and a text area normally displays each as a line break. The words and apparent rows therefore stay the same even though the stored separator differs. To verify it, inspect the result with an editor or byte-level viewer that reports line-ending style; visual comparison cannot distinguish the targets.

Can this turn display wrapping into real newlines?

No. A line that wraps at the edge of the input or output area does not contain a line-ending character at that wrap. The converter has a boundary to rewrite only where CRLF, LF, or CR is actually present. Insert explicit newlines first if separate stored lines are required, then convert those newlines to the desired style.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.