CRLF is obsolete and should be abolished

Definitions

Carriage-Return (CR) → Move the cursor to the left margin
but keep it on the same row.

LineFeed (LF) → Move the cursor down one row, causing all
prior rows to scroll upwards, but keep the cursor on the same column.

NewLine (NL) → Move the cursor down one row and to the left
margin.

Observations
CR and NL are both useful control characters. NL is the most common
operation – start a new line of text at the left margin. CR by itself is
occasionally useful for when you want to overwrite a line of text you
have just written.
LF, on the other hand, is completely useless. Nobody ever wants to be
in the middle of a line, then move down to the next line and continue
writing in the next column from where you left off. No real-world program
ever wants to do that.

LF originated about 70 years ago in the age of mechanical teletype machines.
Teletypes had no transistors. They were constructed purely of gears, cams,
motors, relays, and servos. There were amazing, able to convert binary
codes received over a twisted pair of copper wires into printed text on paper.

Teletypes (technically “teleprinters” – “teletype” was just the most
popular brand name) would print about 5 characters per second. The print
head was a cylindrical or oval ball containing the letters to be printed.
In between the ball and the paper was an cloth ribbon embedded with
ink. To print one character, the ball would twist to the correct position
for that letter and bang forward, causing ink from the ribbon to mark the
paper in the shape of the desired letter. After each letter, the whole
print-head mechanism (the ball and the ink ribbon and various control
cams and gears) would shift to the right by one letter. This was happening
five times per second. These machines made a lot of noise and shook
noticeably when in operation.

At the end of a line of text, the print head would have to traverse all
the way back to the left margin. The print head moved fast, but moving
all the way to the left still took time. There was no memory, and so the
print head had to get all the way over the left before the next printing
character arrived. To facilitate that, the NL operation was divided into
two sub-operations: CR and LF. The CR would go first and start the print
head in motion to the left. While it was still in flight, the LF would
arrive and cause the paper cylinder to rotate up one row. That extra LF
character gave the print head sufficient time to make it all the way
over to the left margin before the next printing character arrived.

Thus, the tradition of ending a line of text with CRLF goes back to the
mechanical limitations of teleprinters from the the 1950s. It is a
classic example of the implementation showing through into the interface.

By the age of Multix and Unix in the late 1960s and early 1970s, most
people recognized that using CRLF as a NL was silly, and so the task
of sending separate CR and LF characters was relegated to the device
drivers for teleprinters, since that is where work-arounds for hardware
quirks belong. The computer sending the text would hold only a single NL
character – adopting the same code for NL as the teleprinters used for LF,
because a true LF is useless in every practical sense and so its numeric
code was available for reuse as NL.

Today, CR is represented by U+000d and both LF and NL are represented
by U+000a. Almost all modern machines use U+000a to mean NL exclusively.
That meaning is embedded in most programming languages as the
backslash escape n.
Nevertheless, a minority of machines still insist on sending a
CR together with their NLs, the official Unicode name for U+000a
is still LF, and various protocols (HTTP, SMTP, CSV) still “require”
CRLF at the end of each line. Almost all software these days will accept
a single NL character without a preceding CR to mean end-of-line.
You need to search really, really hard to find a device or
application that actually interprets U+000a as a true linefeed.

This tradition of sending useless CR characters before every NL, a
tradition that dates back to the era of rotary-dial phones, and before
the invention of integrated circuits, needs to end. There is no reason
in our modern world to continue sending CRLF. The extra CR serves no
useful purpose. It is just a needless complication, a vexation to
programmers, and a waste of bandwidth.

Call To Action
Therefore,
let everyone who seeks peace and simplicity and the flourishing of humanity
join with me in opposing the use of CRLF and helping CRLF move
swiftly towards its ultimate end as an historical curiosity, by
agreeing as follows:

Stop using “linefeed” as the name for the U+000a code point.
Nearly all tech built within
the past two decades, and a majority of tech from the past half
century understands U+000a as a “newline”, not “linefeed”. “Linefeed”
might be its historical name, but who cares. In near universal practice,
it is used as a newline so call it “newline”.

Stop sending unnecessary CRs. Use CR only when you really do want
to overwrite the current line with something new. CR before NL is
a pointless waste of bandwidth. Use CR before NL only in the extreme
case of having to communicate with obstinate systems over which you
have no control and that insist on living in the 1950s.

Even if an established protocol (HTTP, SMTP,
CSV, FTP) technically requires CRLF as a line ending, do not comply.
Send only NL. Almost all implementations of these protocols will
accept a bare NL as an end-of-line mark, even if it is technically
incorrect. Give no quarter to the tyranny of CRLF.

Fix software that misbehaves or raises errors when it receives
a NL without a preceding CR. All modern software should accept a
bare U+000a character as a valid end-of-line mark. Systems may
accept a CR before NL, for backwards compatibility. But software
that requires a CR before NL is broken.

Summary And Authorship
The end of CRLF is long overdue. Let’s work together to put this
anachronism to rest. Let’s make CRLF one less thing that your grandchildren
need to know about or worry about.

Written by D. Richard Hipp, creator of SQLite, Fossil, Althttpd, et cetera,
in Charlotte, NC, USA on 2024-10-10 with minor edits thereafter.