To identify CR, LF, and CRLF in a text editor, compare byte counts in files containing the same text instead of relying on the name shown in a menu. In the tested 20-line specimen, the CR file contained 20 CR bytes and no LF bytes, the LF file contained no CR bytes and 20 LF bytes, and the CRLF file contained 20 of each. Detection returned CR, LF, and CR+LF, while every file contained 180 characters. If a check fails, leave the production manuscript untouched and return to the single 20-line baseline used to create the three copies.
The title-specific status is passed. The run distinguished the three byte patterns and detector results. It did not inspect how external editors visually render their line-ending marks.
Line endings are byte sequences, not visible paragraph shapes
CR means carriage return and LF means line feed. A text file may use CR alone, LF alone, or the two-byte CRLF sequence to represent a line break. All three can look like an ordinary new line on screen.
A controlled comparison therefore keeps the text, logical line count, and encoding constant and changes only the line-ending sequence. Otherwise, a size difference could come from the prose rather than the separators.
Results from the same 20 lines
The specimen used three UTF-8 files with identical content and 20 line breaks.
| Format | Detected value | Characters | CR bytes | LF bytes | Total bytes |
|---|---|---|---|---|---|
| CR | CR | 180 | 20 | 0 | 380 |
| LF | LF | 180 | 0 | 20 | 380 |
| CRLF | CR+LF | 180 | 20 | 20 | 400 |
The CRLF file was 20 bytes larger because each of its 20 breaks used two bytes. Character count alone did not identify the format: all three files reported 180. These values belong to this particular specimen and should not be generalized to a different number of line breaks.
A product-independent comparison
Use this sequence when you need evidence rather than a menu label:
- Create one 20-line baseline and fix its encoding as UTF-8.
- Make three copies and save only the line endings as CR, LF, and CRLF.
- Count CR and LF bytes separately with a byte-level inspection tool.
- Compare those counts with the text editor’s detected line ending.
- Reopen each output and confirm that the 180-character text and 20 logical lines remain the same.
This article explains how the three formats differ. Choosing which one to deliver is a separate policy decision based on the receiver’s documented requirements.
Keep visual display separate from saved bytes
A line-ending display can be useful while editing, but a CRLF label or symbol on screen is not the saved-file evidence. Reopen the output and count the actual CR and LF bytes.
The reverse is also true. A byte-level CRLF result does not establish which glyph, color, or annotation another editor will show. The title-specific limit explicitly leaves external-editor display untested.
Rune Studio’s documented role
Current Rune Studio documentation states that the Mac app supports LF, CRLF, and CR and lets the user switch line-ending settings from the status bar. Those are Stage 3 product capabilities.
The title-specific Stage 4 run inspected the three 20-line files and recorded their CR/LF counts, detector values, character counts, and total byte sizes. It did not capture visual line-ending marks or compare another application.
A separate common Stage 4 run inspected one short text across five encodings, all using LF. UTF-8, Shift_JIS, and EUC-JP returned 39 characters; UTF-16LE and UTF-16BE returned 40. The working tab read back UTF-8. That result is supporting encoding evidence, not the proof that distinguishes CR from LF and CRLF.
Rune Studio’s encoding-error behavior also belongs to a different claim. The documented wording is that autosave pauses while unrepresentable characters remain and manual save produces a warning. It should not be shortened to a claim that every save is blocked.
Rollback points
- If CR and LF totals do not match the planned format, discard the three copies and return to the 20-line baseline.
- If character count changes from 180, remove the unintended text difference before comparing line endings.
- If detector output conflicts with the byte counts, leave detection unresolved and repeat the byte inspection.
- If the receiver’s required line ending is unknown, do not convert the production file; return to the receiver’s specification.
Complete recovery of damaged data, OCR, and binary repair are outside scope. Acceptance by an external application after line-ending conversion was not tested.
Conclusion: compare the separators, not just the label
For the same 20-line UTF-8 text, CR produced 20/0 CR/LF bytes, LF produced 0/20, and CRLF produced 20/20. Detection returned CR, LF, and CR+LF. Every file contained 180 characters, while CRLF alone grew to 400 bytes instead of 380.
This is a format-comparison guide. BOM detection, Shift_JIS representability, and saving a UTF-8 conversion with a chosen line ending are separate workflows with different exit conditions. The current Mac feature scope is available on the Rune Studio product page.