CRLF vs LF: Line Endings Explained (Windows, Mac, Linux)
Learn how CRLF and LF mark line breaks, why they matter for Git, shell scripts, and CSV imports, and how to check or convert the line endings in a file.
CRLF vs LF in one sentence
CRLF marks a line break with two characters, carriage return and line feed (\r\n), while LF uses just the line feed (\n). Most current editors display them the same way. A shell, import tool, or Git checkout can still treat the underlying bytes differently.
What do CR and LF mean?
CR is carriage return, written \r in many programming languages and stored as 0D in ASCII and UTF-8. LF is line feed, written \n and stored as 0A. The names come from mechanical writing and printing. Returning the carriage moved the print position back to the start of the line. Feeding the paper moved it to the next line. A carriage return followed by a line feed combined both motions.
In a text file, the characters function as markers. For example, here are the bytes of two UTF-8 lines, each holding one letter, with no line break after the second letter:
| Convention | Escaped representation | Bytes in hexadecimal |
|---|---|---|
| LF | A\nB | 41 0A 42 |
| CRLF | A\r\nB | 41 0D 0A 42 |
| CR | A\rB | 41 0D 42 |
The backslashes in the middle column describe the control characters. Typing the two literal characters \ and n into a text editor produces different bytes. Press Enter or choose a line-ending setting when you want an actual line break. These examples assume UTF-8, which uses one byte for each of these control characters. Other encodings, such as UTF-16, store them differently.
Which systems use which line ending?
| System or workflow | Usual convention | Where you may see it |
|---|---|---|
| Windows | CRLF (\r\n) | Windows-native utilities and some export workflows |
| macOS, Linux, and Unix | LF (\n) | Source files, shell scripts, and text tools |
| Classic Mac OS before Mac OS X | CR (\r) | Archives or files from older systems |
These are conventions. A file transferred from one system retains its original bytes until an editor or conversion tool rewrites it. A file created on Windows can use LF. Modern Windows Notepad supports LF and CR in addition to CRLF. Microsoft's announcement of extended line-ending support
When line endings cause problems
A shell script fails with bad interpreter or ^M
A Unix shell script commonly starts with a shebang, such as #!/bin/bash. If the line ends in CRLF, the system can read the carriage return as part of the interpreter path, leading to an error such as /bin/bash^M: bad interpreter. Error wording differs by system. The ^M represents the carriage return. Convert the script to LF, then test it in the environment where it runs. If a file is checked out in a different environment as part of a build, check that copy too.
Git shows a large diff or warns about line endings
Switching every newline can make a short edit appear to change an entire file. Git can normalize text to LF in its index and check it out with LF or CRLF in the working tree. A warning like LF will be replaced by CRLF refers to a conversion Git expects under its current configuration. Check the repository's attributes before making an editor-wide change. If a project intentionally normalizes existing files, a dedicated change makes it easier to review separately from edits to the content. Git's documentation on text attributes
An import reads one row or includes stray characters
A data importer may expect a specific record separator. RFC 4180 describes CSV records separated by CRLF and allows implementations to differ. For a plain text import, check the receiving system's specification. If you're processing CSV with quoted fields that can contain line breaks, use a CSV-aware reader to validate the result. Splitting the text at every newline may break a single quoted field into several records. RFC 4180 on CSV files
Old Notepad displays one long line
Older Windows Notepad versions did not display Unix LF breaks as expected. Open the file in a modern editor to check it. If someone needs the file for a legacy application that expects CRLF, save a CRLF copy and leave the original available for other workflows.
How to check and convert line endings
VS Code and Notepad++
- In VS Code, open a text file and look for LF or CRLF in the status bar. Click the indicator, choose the desired line-ending sequence, and save the document. VS Code's status bar implementation
- In Notepad++, open the file and use Edit › EOL Conversion. Choose Unix (LF) or Windows (CR LF), then save. Macintosh (CR) is for the older Mac convention. The Notepad++ editing guide
A status bar reports the convention detected or selected for the document. If you suspect a mix, inspect several line ends in a byte viewer. In UTF-8, look for 0A alone and 0D 0A in different places. Mixed endings can creep into a file through pasted content or a partial conversion.
dos2unix and unix2dos
If the dos2unix package is available, use its -n option to write a copy. The first example starts with a Windows-style file and outputs LF. The second starts with a Unix-style file and outputs CRLF. Use these examples with ordinary UTF-8 input. With other encodings or BOMs, review the tool's options before converting, because it can affect those properties as well.
dos2unix -n windows.txt unix-copy.txt
unix2dos -n unix.txt windows-copy.txt
Reopen the copy and verify it with the recipient's tool before replacing a file in a shared workflow. The dos2unix manual
Git and .gitattributes
core.autocrlf=true can make Git normalize text on input and check it out with CRLF. core.autocrlf=input enables normalization on input without requesting CRLF conversion on checkout. For a shared project, add a policy to .gitattributes. This example asks Git to detect text and use LF in the working tree for matching text files:
* text=auto eol=lf
You can scope rules to particular file types, such as *.sh text eol=lf, when a project needs different endings for different consumers. A new rule also does not immediately rewrite every file already in the repository. Follow the documented renormalization process if you need to update files already checked in. Git configuration reference, Git attributes reference
Which one should you use?
Use the receiving system's documented requirement when there is one. LF is a reasonable default for a new cross-platform text file, and it is the normal choice for Unix shell scripts. Use CRLF for an import, application, or established project that expects it. Preserve a repository's current convention unless the project is changing it on purpose.
For ordinary notes that people read in current editors, either style generally works. The important compatibility choice may be UTF-8 instead. If punctuation or accented letters turn into strange characters, check the encoding first. What a TXT file stores
Create a file with the line ending you need
Open the TXT editor, enter your text, then choose LF or CRLF under Line endings. Set the encoding separately, name the file, and download it. If you're adjusting an existing file for an import, keep an original copy until the converted file passes the import.
FAQ
Is CRLF the same as pressing Enter twice?
No. CR and LF form one line break under the CRLF convention. Two successive CRLF sequences produce two line breaks.
Do I need a newline at the end of the file?
Follow the receiving format or project convention. Some tools expect a final newline. It marks the end of the last line and can make later appends behave predictably. Other formats accept a final record either way.
Will changing LF to CRLF fix garbled characters?
It changes the end-of-line markers. If the words themselves are garbled, reopen the original with its source encoding and check that the text is intact before saving it again.