LF, CRLF, and CR can produce identical-looking lines while storing different bytes. The right choice is not a contest between operating systems; it is the convention required by the repository, importer, or person receiving the file. A text editor helps when it shows the current line-ending mode clearly and lets you verify the saved result after reopening.
Three names, three byte patterns
LF uses a line-feed byte. CRLF uses a carriage return followed by a line feed. CR uses a carriage return alone and is mostly encountered in older material. Modern macOS and Unix-oriented projects commonly use LF, while Windows-oriented workflows commonly use CRLF, but existing project rules override those broad habits.
The filename does not settle the question. Two .txt files can use different endings, and the prose can look the same in both. Record the encoding and line ending together, such as UTF-8 / LF, because UTF-8 versus Shift_JIS and LF versus CRLF are independent decisions.
A twenty-line comparison makes the difference visible
Save the same twenty lines as three separate files, one for each mode. In a controlled comparison, the newline bytes were 10 for LF, 13,10 for CRLF, and 13 for CR. The resulting files had three distinct fingerprints even though reopening them produced the same visible sentences.
That result explains a familiar mystery: a version-control diff can mark every line as changed after a tiny edit. The words may be untouched; the editor has rewritten every line ending. It also explains why an importer may join lines or insert blank ones when it assumes a convention different from the file’s actual convention.
Diagnose the symptom before converting anything
- If a diff shows every line changed, compare the old and new line-ending modes.
- If an importing system joins or doubles lines, check its documented input convention.
- If collaborators keep reversing each other’s changes, agree on one project rule and configure editors consistently.
Do not normalize a delivery file merely because LF is common on a Mac. A legacy business system, a test fixture, or a client specification may deliberately require CRLF or CR. In those cases preservation, not modernization, is the correct outcome.
How to make a controlled change in Rune Studio
Open a duplicate and read the encoding and line-ending indicators for the tab. Decide whether you are changing one file or normalizing an entire project; those are different scopes. Use Save As for the trial result, choose the required line-ending mode, close the saved tab, and reopen it from disk.
After reopening, confirm the reported mode, the line count, the final line, and any intentional blank lines. This checks both the setting and the stored result. It also gives you a small file that can be tested in the destination system before you transform a whole collection.
A sensible default and its exceptions
For a new cross-platform source repository, follow the repository’s declared convention and enforce it consistently. For an existing manuscript or data exchange, preserve the current mode unless the destination requires a change. For archival material, keep the original and create a converted derivative so the historical bytes remain available.
Rune Studio is useful when you want line endings and Japanese encodings visible in the same editing workflow. It cannot decide what an external system expects, so that requirement must come first. See the current format support on the Rune Studio product page, then test one representative file in its real destination before applying a batch conversion.