CRLF stands for Carriage Return (CR, ASCII 13 or \r) followed by Line Feed (LF, ASCII 10 or \n). This sequence represents a newline in Windows systems, while Unix-like systems typically use just LF. The terminology comes from typewriter days: CR returned the carriage to the start position, while LF advanced the paper by one line.

Different operating systems handle line endings differently:

// Windows style (CRLF)
"This is line 1\r\nThis is line 2"

// Unix/Linux/MacOS style (LF)
"This is line 1\nThis is line 2"

// Old MacOS style (CR) - now rare
"This is line 1\rThis is line 2"

CRLF issues commonly surface in:

• Version control systems (Git showing entire file as modified)
• Cross-platform file processing
• Network protocols (HTTP headers require CRLF)
• File parsing operations

Modern languages provide tools to handle line endings:

# Python example with universal newlines
with open('file.txt', 'r', newline='') as f:
    lines = f.readlines()  # Automatically converts to \n

// JavaScript line ending normalization
const text = fileContent.replace(/\r\n/g, '\n');

To prevent CRLF issues in Git repositories:

# Core Git configuration
git config --global core.autocrlf input  # For Linux/Mac
git config --global core.autocrlf true   # For Windows

# .gitattributes file solution
* text=auto
*.sh text eol=lf
*.bat text eol=crlf

The HTTP/1.1 specification mandates CRLF for headers:

// Correct HTTP header format
const httpResponse = 'HTTP/1.1 200 OK\r\n' +
                     'Content-Type: text/plain\r\n' +
                     '\r\n' +
                     'Hello World';

When working with text files:

• Use text editors that show line endings (VS Code, Notepad++)
• Be explicit about line endings in file operations
• Normalize line endings when processing cross-platform files
• Consider using the os.EOL constant in Node.js

html

CRLF stands for Carriage Return (CR) and Line Feed (LF), which are control characters used to signify the end of a line in text files. Historically, CR (ASCII 13 or \r) and LF (ASCII 10 or \n) originated from typewriter and printer mechanics, but they remain relevant in modern computing, especially in file formats and network protocols.

Carriage Return (CR) moves the cursor to the beginning of the line without advancing to the next line. Line Feed (LF) advances the cursor to the next line without returning to the start. Together (\r\n), they emulate a full "new line" operation.

Different operating systems handle line endings differently:

• Windows: Uses CRLF (\r\n) as the standard line terminator.
• Unix/Linux/macOS: Uses LF (\n) exclusively.
• Classic Mac OS (pre-OS X): Used CR (\r).

Here’s how CRLF is handled in various programming languages:

Python

# Writing a file with CRLF line endings (Windows-style)
with open('example.txt', 'w', newline='\r\n') as file:
    file.write('Line 1\r\nLine 2\r\n')

JavaScript (Node.js)

// Normalizing line endings to LF
const text = fs.readFileSync('file.txt', 'utf8').replace(/\r\n/g, '\n');

C#

// Environment.NewLine adapts to the OS default (CRLF on Windows)
string lineBreak = Environment.NewLine;
Console.WriteLine($"Hello{lineBreak}World");

Git and Line Endings: Git can auto-convert CRLF to LF (or vice versa) using .gitattributes:

* text=auto

HTTP Headers: CRLF is mandatory in HTTP headers (RFC 2616). Misuse can lead to injection attacks (e.g., HTTP Response Splitting). Example of a valid header:

HTTP/1.1 200 OK\r\nContent-Type: text/html\r\n\r\n

Inconsistent line endings can cause:

• Version control conflicts (e.g., Git marking entire files as modified).
• Parser errors in JSON/XML files.
• Security vulnerabilities in network protocols.