1255

I'd like to know the difference (with examples if possible) between CR LF (Windows), LF (Unix) and CR (Macintosh) line break types.

Improve this question
6
  • 10
    1279779 is very similar, but not an exact duplicate. \n is typically represented by a linefeed, but it's not necessarily a linefeed. Commented Mar 2, 2012 at 0:00
  • 163
    CR and LF are ASCII and Unicode control characters while \r and \n are abstractions used in certain programming languages. Closing this question glosses over fundamental differences between the questions and perpetuates misinformation. Commented Oct 8, 2012 at 20:07
  • This formulation of the question is admittedly better, but it is still for all practical purposes the same question. Commented Mar 13, 2014 at 17:22
  • 12
    @JukkaK.Korpela: No, it really isn't. \n doesn't mean the same thing in all programming languages. Commented Mar 13, 2014 at 17:34
  • @AdrianMcCarthy, what operating system puts "CR" and/or "LF" at the end of a line to indicate that it is the end of the line? I have never heard of any. If you are saying that CR and LF are representations of the codes for carriage return and line feed then that makes sense and "\r" and "\n" are also representations. Commented Apr 3, 2017 at 9:09

10 Answers 10

Reset to default
1204

CR and LF are control characters, respectively coded 0x0D (13 decimal) and 0x0A (10 decimal).

They are used to mark a line break in a text file. As you indicated, Windows uses two characters the CR LF sequence; Unix (and macOS starting with Mac OS X 10.0) only uses LF; and the classic Mac OS (before 10.0) used CR.

An apocryphal historical perspective:

As indicated by Peter, CR = Carriage Return and LF = Line Feed, two expressions have their roots in the old typewriters / TTY. LF moved the paper up (but kept the horizontal position identical) and CR brought back the "carriage" so that the next character typed would be at the leftmost position on the paper (but on the same line). CR+LF was doing both, i.e., preparing to type a new line. As time went by the physical semantics of the codes were not applicable, and as memory and floppy disk space were at a premium, some OS designers decided to only use one of the characters, they just didn't communicate very well with one another ;-)

Most modern text editors and text-oriented applications offer options/settings, etc. that allow the automatic detection of the file's end-of-line convention and to display it accordingly.

Improve this answer
Sign up to request clarification or add additional context in comments.

13 Comments

so actually Windows is the only OS that uses these characters properly, Carriage Return, followed by a Line Feed.
IMO, "properly" is a matter of opinion based in whether you contextualize "proper" historically or in view of conventions long established since then, i.e. the environment of a teleprinter or the environment of a VDU, standard for for more than 50 years. In terms of the original intended meaning of those symbols, yes, but the original intended meaning is archaic. The altered meanings are also such very long-standing well-established standards that, within those contexts, it's crucial to accept the varying meanings attached are indeed the proper meanings. That's the point of standardisati
Unicode nowadays provides a single "next line" (NEL) control code.
The same applies with your new comment: It's merely the lingua-franca of whatever environment you are using. Maybe Unicode does have new control codes. Fine, but not all systems support or use Unicode. So it's back to square one: What the meaning of a symbol - or symbol system - is, and whether that symbol - or symbol system - has any meaning at all, depends entirely on how that symbol - or symbol system -is defined, or not defined, in the environment you are using.
Would it be accurate, then, to say that a text file created on Windows is the most compatible of the three i.e. the most likely to display on all three OS subsets?
@Hashim it might display properly but trying to run a textual shell script with carriage returns will usually result in an error
Rolf - that statement assumes that keeping old terminology/technology in new technology is correct. CRLF = 2 bytes. CR = 1, LF = 1. With as often as they are used, that actually translates to a huge amount of data. Once again, Windows has chosen to be different from the entirety of the *NIX world.
@QuaternionsRock The short is answer is because CR takes a long time on a teleprinter. Putting CR before LF gives the carriage time to get back to the other side. Sometimes even with CRLF you'd have to send NULs to give it more time.
|
648

This is a good summary I found:

The Carriage Return (CR) character (0x0D, \r) moves the cursor to the beginning of the line without advancing to the next line. This character is used as a new line character in Commodore and early Macintosh operating systems (Mac OS 9 and earlier).

The Line Feed (LF) character (0x0A, \n) moves the cursor down to the next line without returning to the beginning of the line. This character is used as a new line character in Unix-based systems (Linux, Mac OS X, etc.)

The End of Line (EOL) sequence (0x0D 0x0A, \r\n) is actually two ASCII characters, a combination of the CR and LF characters. It moves the cursor both down to the next line and to the beginning of that line. This character is used as a new line character in most other non-Unix operating systems including Microsoft Windows, Symbian and others.

Source

Improve this answer

4 Comments

The "vertical tab"-character moves the cursor down and keep the position in the line, not the LF-character. The LF is EOL.
@TaylorLeese Are /r/n and /n/r same?
Thanks for highlighting: Classic MacOS: CR = \r, Unix and MacOS: LF = \n, Windows: CRLF = \r\n.
@Vicrobot Developers will often split a string or perform other operations with the exact sequence \r\n, so \n\r would not match. Also one would think that text editors also treat the two characters as one sequence and don't separatly go "oh, now I have to go down one line" and "oh, now I have to move to the front". Were it so then yes, you could freely swap the order around
477

It's really just about which bytes are stored in a file. CR is a bytecode for carriage return (from the days of typewriters) and LF similarly, for line feed. It just refers to the bytes that are placed as end-of-line markers.

There is way more information, as always, on Wikipedia.

Improve this answer

5 Comments

I think it's also useful to mention that CR is the escape character \r and LF is the escape character \n. In addition, Wikipedia:Newline.
In Simple words CR and LF is just end of line and new line according to this link , is this correct ?
@shaijut CR stands for Carriage Return. That was what returned the carriage on typewriters. So, mostly correct.
The superior LFCR option is sadly missing. Its benefit is that by doing the Line Feed first, the Selectric golfball can't smear the just printed line with still fresh ink upon executing the Carriage Return </s>
Actually, it's not a typewriter but "teletype", old computer client terminals with mechanical print heads and paper, where CR/LF were required for computers to behave properly. If you just did CR, you would have a bunch of characters on top of each other on a paper. If you just did LF, your text lines would slowly migrate to the right on the paper. CR/LF were required for proper teletype based computing. An old Star Trek game would dump "F<LF><BEL><BEL>I<LF><BEL><BEL>R<LF><BEL><BEL>I<LF><BEL><BEL>N<LF><BEL><BEL>G<LF><BEL><BEL>" diagonally down the page.
248

Summarized succinctly:

Carriage Return (Mac pre-OS X)

  • CR
  • \r
  • ASCII code 13

Line Feed (Linux, Mac OS X)

  • LF
  • \n
  • ASCII code 10

Carriage Return and Line Feed (Windows)

  • CRLF
  • \r\n
  • ASCII code 13 and then ASCII code 10

If you see ASCII code in a strange format, they are merely the number 13 and 10 in a different radix/base, usually base 8 (octal) or base 16 (hexadecimal).

ASCII chart

Improve this answer

3 Comments

The \r and \n only works in some programming languages, although it seems to be universal among programming languages that use backslash to indicate special characters.
@Flimm yes, backslash is the commonly designated character to "escape" what follows it.
And RISCOS uses \n\r
55

Jeff Atwood has a blog post about this: The Great Newline Schism

Here is the essence from Wikipedia:

The sequence CR+LF was in common use on many early computer systems that had adopted teletype machines, typically an ASR33, as a console device, because this sequence was required to position those printers at the start of a new line. On these systems, text was often routinely composed to be compatible with these printers, since the concept of device drivers hiding such hardware details from the application was not yet well developed; applications had to talk directly to the teletype machine and follow its conventions. The separation of the two functions concealed the fact that the print head could not return from the far right to the beginning of the next line in one-character time. That is why the sequence was always sent with the CR first. In fact, it was often necessary to send extra characters (extraneous CRs or NULs, which are ignored) to give the print head time to move to the left margin. Even after teletypes were replaced by computer terminals with higher baud rates, many operating systems still supported automatic sending of these fill characters, for compatibility with cheaper terminals that required multiple character times to scroll the display.

Improve this answer

10 Comments

+1 It is by this simple understanding that I always remember in what order the combination comes. Even today we can still see this mechanical logic in any inktjet-printer (I love to understand since I hate to learn). My other memory-tricks are: "mac? Return to sender" and "NewLineFeed" (to remember that NL===LF and to remember the \n , since CR already has the R in it's abbreviation)
"I'm dubious ... two control codes was necessary for timing". That's not what it says. It says that the extra CRs and NULs are here for giving time for it to come back, not the original CR LF.
@Adrian Will you take persona experience? 1) In my old teletype days, the printer we used required <CR><CR><LF> - so of course I experimented with just one <CR>. I sent <CR><LF>A after a long line, and you could hear the A being printed before the carriage fully returned.
@Adrian 2) Don't forget, this was in the electro-mechanical era, where each character did exactly one function. We often emphasised a word by printing the line, then sending <CR><CR> and typing the correct number of spaces, then re-printing the same word: a primitive form of bolding.
@Adrian 3) And finally, this was using Baudot (or Murray code), not ASCII. Five data bits, between one start bit and one-and-a-half stop bits. How can you have half a bit? By waiting half a bit time before starting to send the next character, to give the print head time to return to center.
|
19

CR - ASCII code 13

LF - ASCII code 10.

Theoretically, CR returns the cursor to the first position (on the left). LF feeds one line, moving the cursor one line down. This is how in the old days you controlled printers and text-mode monitors.

These characters are usually used to mark end of lines in text files. Different operating systems used different conventions. As you pointed out, Windows uses the CR/LF combination while pre-OS X Macs use just CR and so on.

Improve this answer

Comments

13

CR and LF are a special set of characters that help us format our code.

  1. CR (\r) stands for CARRIAGE RETURN. It puts the cursor at the beginning of a line, but it doesn't create a new line. This is how classic Mac OS works (not applicable today unless you are dealing with old files).

  2. LF (\n) stands for LINE FEED. It creates a new line, but it doesn't put the cursor at the beginning of that line. The cursor stays back at the end of the last line. This is how Unix (including macOS) and Linux work.

  3. CRLF (\r\n) creates a new line as well as puts the cursor at the beginning of the new line. This is how we see it in Windows OS.

Git uses LF by default. So when we use Git on Windows it throws a warning like "CRLF will be replaced by LF" and automatically converts all CRLF into LF, so that code becomes compatible.

NB: Don't worry...see this less as a warning and more as a notice thing.

Improve this answer

1 Comment

Re "This is how MAC OS works": Only the old Macs (Classic Mac OS).
11

The sad state of "record separators" or "line terminators" is a legacy of the dark ages of computing.

Now, we take it for granted that anything we want to represent is in some way structured data and conforms to various abstractions that define lines, files, protocols, messages, markup, whatever.

But once upon a time this wasn't exactly true. Applications built-in control characters and device-specific processing. The brain-dead systems that required both CR and LF simply had no abstraction for record separators or line terminators. The CR was necessary in order to get the teletype or video display to return to column one and the LF (today, NL, same code) was necessary to get it to advance to the next line. I guess the idea of doing something other than dumping the raw data to the device was too complex.

Unix and Mac actually specified an abstraction for the line end, imagine that. Sadly, they specified different ones. (Unix, ahem, came first.) And naturally, they used a control code that was already "close" to S.O.P.

Since almost all of our operating software today is a descendent of Unix, Mac, or Microsoft operating software, we are stuck with the line ending confusion.

Improve this answer

Comments

7

Systems based on ASCII or a compatible character set use either LF (Line feed, 0x0A, 10 in decimal) or CR (Carriage return, 0x0D, 13 in decimal) individually, or CR followed by LF (CR+LF, 0x0D 0x0A); These characters are based on printer commands: The line feed indicated that one line of paper should feed out of the printer, and a carriage return indicated that the printer carriage should return to the beginning of the current line.

Here is the details.

Improve this answer

Comments

2

NL is derived from EBCDIC NL = 0x15 which would logically compare to CRLF 0x0D 0x0A ASCII... This becomes evident when physically moving data from mainframes to midrange. Colloquially (as only arcane folks use EBCDIC), NL has been equated with either CR or LF or CRLF.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.