What does Carriage Return usage actually mean?

On a typewriter, 'carriage return' physically slid the paper carriage back to the left margin. ASCII CR (code 13) does the digital equivalent — it moves the cursor to the beginning of the current line without advancing to a new line. That's why it's paired with LF on Windows.

Why does Windows use CR+LF while Unix uses just LF?

Windows inherited CRLF from teletype conventions and DOS (which got it from CP/M). Unix chose to simplify: one byte (LF) for one action (new line). Both approaches work — the problem is only when files cross platform boundaries without conversion.

What are those ^M characters at the end of my lines?

That's the CR byte (0x0D) made visible in caret notation. You're looking at a Windows-format (CRLF) file in a Unix tool that only expects LF. Fix it with dos2unix, sed 's/\r$//', or configure your editor to convert line endings.

How do I remove ^M characters from a file?

The easiest way is the 'dos2unix' tool. Alternatively, use sed: `sed -i 's/\r//' filename`. In Vim, type `:%s/\r//g`. These commands strip the Carriage Return byte, leaving just the Unix-standard Line Feed.

Can CR be used to overwrite text on the same line?

Yes, and it's a useful trick. Printing \r moves the cursor back to column 1 without advancing to a new line, so the next print overwrites the current line. Progress bars and status indicators in CLIs use this to update in place without scrolling.

Do HTTP headers utilize CR?

Yes. The HTTP specification requires headers to be separated by CRLF (\r\n), not just LF. While many servers are lenient and accept LF-only, strictly compliant clients and servers must generate CRLF headers.

Why is it called 'Carriage Return'?

It refers to the platen carriage of a mechanical typewriter. After typing a line, you had to push a lever to slide the carriage all the way back to the right (so you could type on the left). ASCII 13 was the code that triggered this motor action on teletypes.

Is CR ever used as a newline on its own?

Historically, yes. Classic Mac/OS (pre-OS X) used CR alone as its newline character. Some very old systems and Lisp machines did too. Modern systems almost exclusively use LF (Unix) or CRLF (Windows).

Carriage Return

CR (Carriage Return) is ASCII code point 13 (0x0D), Unicode U+000D, and a control character. If you've ever seen `^M` littered across a file in vim, or a progress bar in a terminal that overwrites itself in place, CR is what's behind both. It moves the cursor back to the beginning of the current line without advancing downward. The `\r` escape is where most developers meet it, usually involuntarily. Windows line endings are `\r\n` — CR followed by LF — while Unix uses bare `\n`, and this mismatch is the single most common cause of line-ending bugs. Git's `core.autocrlf` setting exists entirely to manage this. On its own, `\r` is useful for overwriting terminal output in place: CLI progress bars and spinners work by printing `\r` then writing new text over the old. In HTTP, every header line must end with `\r\n` per the spec, and servers that don't enforce this reject requests silently. CSV files from Excel on Windows arrive packed with `\r\n`, which can produce ghost empty lines if your parser splits on `\n` without stripping `\r`. The name is literal: on a typewriter, the carriage — the mechanism holding the paper — physically returned to the left margin when you pushed the lever. Teletypes automated this as a control code, and paired it with LF to mean "new line and reset position," a two-step process that Unix later simplified to just LF. UTF-8 encodes it as a single byte 0x0D, identical to its ASCII value. Unicode classifies it as Cc (Control, Other) under the official name CARRIAGE RETURN. Almost always discussed alongside LF (U+000A), and the two are so tightly linked that many APIs abstract them into a single "newline" concept — which is exactly why bugs appear when that abstraction leaks.

Whitespace

Technical Details

Code Example

</>

char *line = "GET / HTTP/1.1\r\nHost: example.com\r\n\r\n";
char *end = strstr(line, "\r\n\r\n");
// HTTP headers end at CRLF CRLF
size_t header_len = end ? (size_t)(end - line) : 0;

Frequently Asked Questions

On a typewriter, 'carriage return' physically slid the paper carriage back to the left margin. ASCII CR (code 13) does the digital equivalent — it moves the cursor to the beginning of the current line without advancing to a new line. That's why it's paired with LF on Windows.
Windows inherited CRLF from teletype conventions and DOS (which got it from CP/M). Unix chose to simplify: one byte (LF) for one action (new line). Both approaches work — the problem is only when files cross platform boundaries without conversion.
That's the CR byte (0x0D) made visible in caret notation. You're looking at a Windows-format (CRLF) file in a Unix tool that only expects LF. Fix it with dos2unix, sed 's/\r$//', or configure your editor to convert line endings.
The easiest way is the 'dos2unix' tool. Alternatively, use sed: `sed -i 's/\r//' filename`. In Vim, type `:%s/\r//g`. These commands strip the Carriage Return byte, leaving just the Unix-standard Line Feed.
Yes, and it's a useful trick. Printing \r moves the cursor back to column 1 without advancing to a new line, so the next print overwrites the current line. Progress bars and status indicators in CLIs use this to update in place without scrolling.
Yes. The HTTP specification requires headers to be separated by CRLF (\r\n), not just LF. While many servers are lenient and accept LF-only, strictly compliant clients and servers must generate CRLF headers.
It refers to the platen carriage of a mechanical typewriter. After typing a line, you had to push a lever to slide the carriage all the way back to the right (so you could type on the left). ASCII 13 was the code that triggered this motor action on teletypes.
Historically, yes. Classic Mac/OS (pre-OS X) used CR alone as its newline character. Some very old systems and Lisp machines did too. Modern systems almost exclusively use LF (Unix) or CRLF (Windows).

Carriage Return

Whitespace