Why do line breaks look different in text files from different systems?

The visible layout does not necessarily reveal the characters stored between lines. Two common line-ending conventions are LF, a line-feed character alone, and CRLF, a carriage return followed by a line feed. Visual Studio’s documentation defines CRLF as U+000D followed by U+000A, and LF as U+000A. [S1]

An editor may render either sequence as an ordinary new line. For example, these boundaries differ even if the words look alike on screen:

• LF: North + line feed + South
• CRLF: North + carriage return + line feed + South

The labels describe the stored characters; they are not text to type. If an editor hides control characters, appearance alone cannot establish which sequence the file uses.

Use a line-ending indicator or a feature that displays control characters, if your editor provides one. An indicator that reports LF or CRLF is a clue about the line-ending type the editor recognizes; the location and wording of such indicators depend on the application.

The basic comparison is:

• LF: one line-feed character at the boundary.
• CRLF: a carriage return followed immediately by a line feed.

If you inspect the characters directly, check the boundary between lines. Also check more than one boundary if you need to know whether the file is consistent. Visual Studio documents that it can encounter multiple line-break characters and may prompt about normalizing inconsistent ones. That describes Visual Studio, not every editor. [S1]

Applications can have different rules for recognizing and presenting line boundaries, so do not assume that what one app displays establishes how another will handle the file. The supplied documentation gives a specific example: .NET’s File.ReadLines treats a carriage return, a line feed, CR immediately followed by LF, or the end of a file or stream as a line boundary. Code using that method may therefore present the same line content despite different terminators. [S2]

That is evidence about this .NET method only; it does not establish that every application displays, reads, or normalizes line endings the same way. To compare two apps, inspect the file in each and note what each reports. If you are checking whether the file itself changed, avoid saving it during the comparison.

Use a read-only inspection where possible. Note the reported line-ending type, inspect several boundaries if the tool allows it, and look for signs of mixed endings. If an application asks whether to normalize inconsistent breaks, do not confirm that prompt when you only intend to inspect. Visual Studio can be configured to apply a chosen line-break type when saving, so saving there may change the line breaks. This is Visual Studio-specific behavior, not a claim about every editor. [S1]

A concise comparison record could be:

File A: reported LF; inspected boundaries use LF. File B: reported CRLF; inspected boundaries use CRLF. Result: same visible lines, different line-ending sequences.

Limit the conclusion to the files and boundaries you checked. A visible layout does not identify the stored sequence, and one application’s behavior does not establish how another will handle it.