A follow-up to Difference between '\n' and '\r\n'.

It's been few decades since the schism was introduced. Nowadays, when documents are being exchanged over the internet, typically with no prior knowledge of the client's preference of line endings, the clients have to deal with both \n, \r\n.

To me it seems that it's safe to use \n only. Software produced by Microsoft can process both. The major plain text editors can too. Browsers, IDEs, file managers, office suites, all these can do it.

Is there any point in writing software to use CRLF or is it practically ok to just unify at "\n"? Are there known problems with "\n" in any major modern Windows software?

EDIT: The issue is not with the software itself. Indeed the software can use some kind of NL constant which resolves at runtime. However, the generated files are about to be transferred, and hardly converted on each occasion.

Imagine a company where the originating machine of a content/document can be any platform, and the consuming too. And the way of transferring the documents can be any (mail, shared drive, download,...) In such scenario, there is no way to prevent content using \n appearing on Windows, and vice versa. Hence the question.

  • There may be problems with tools that expect Windows style endings, e.g. from Excel-exported .csv tabular data containing files. Of course, that can be dealt with when it happens and the issue also exists the other way around.
    – Mörre
    Sep 30, 2017 at 6:35
  • 2
    Recommended reading about backwards compatibility: joelonsoftware.com/2008/03/17/martian-headsets
    – Doc Brown
    Sep 30, 2017 at 7:19
  • There is way much more text processing software out there than a single person including me and you know. ' \r\n' needs be understood by any of those under Windows, opposed to '\n'. So as long as you want to keep your programs backwards compatible, better play it safe and use ' \r\n'. And what do you lose? For example, in C#, I often use functions like "WriteLine" or "AppendLine" which use the system's correct line breaks automatically, I seldom use a thought about this.
    – Doc Brown
    Oct 1, 2017 at 6:59
  • Specifications written for HTTP and other web standards require \r\n.
    – Rob
    Oct 9, 2017 at 2:03
  • 1
    @Austin_Anderson: in the original question, before the last edit, the OP was not specificially talking about software for data exchange with other, unknown platforms. That puts it in a different light.
    – Doc Brown
    Oct 9, 2017 at 15:02

4 Answers 4


As far as Windows and C# is involved you can always use the Environment.Newline

to determine the default new line character of the system the program is ran on.

also, you can use text.Replace("\n","\r\n") to switch to windows return.

There are still compatibility issues when managing files and especially office related ones, some arcane COM apis are also newline sensitive.


This question is really about a software application's "customer base".

To answer your question, you have to know whether your customers might be inconvenienced if your application generates output text files which are only \n and don't provide an option of outputting \r\n. The best way to find out is to ask your real customers.

From a programmer's point of view, adding an option for choosing the newline in output text files is a relative small task. Alternatively, one can automatically choose \n and \r\n based on the platform. Also, most text line handling library functions already handle both \n and \r\n, without programmer's effort.

If you are writing a library, you can either return the data in strings, which completely sidestep the question of newlines, or to use the text file handling facility that comes with the programming language.

However, if you are distributing archives (e.g. ZIP files) containing text-based files, it would indeed seem redundant to provide two sets of archives: one ZIP file where all text files have \r\n newlines, another where all newlines are \n. Typically, this problem is solved by combining it with another network-effect problem, the favorite file compression format for each platform:

  • Provide a ZIP with newlines \r\n
  • Provide a TGZ with newlines \n

Windows Notepad (notepad.exe) doesn't interpret a standalone \n as a new line. It's not necessarily "modern" but pretty much "mainstream".

If you're writing text files, every day user should be able to edit, don't focus on \n only and instead write your program in a way to accept all three styles (since some older programs might even use \r only).

  • Well, ok, it's installed in all Windows, but I think even Microsoft doesn't mean that as a real text editing app. Originally it has been a demo app for WinAPI and nowadays it's rather a relic. Sep 30, 2017 at 23:44
  • 2
    @OndraŽižka Well, it's no full weird processor, yet it's still the default for editing plain text for most users.
    – Mario
    Oct 1, 2017 at 6:18
  • This all boils down to: do you only want to write software with the installation requirement "needs a text editor with unix-compatible line break interpretation to be preinstalled"? Or do you prefer to write software with the installation requirements "needs nothing but a naked Windows installation"?
    – Doc Brown
    Oct 1, 2017 at 7:03
  • @DocBrown, naked Windows installation has WordPad, which is capable of parsing \n. notepad.exe has several other limits, like max. size 64 kB, if I remember correctly. So I'm rather asking about the modern programs, since as a non-windows user I can be missing some important one which insists on CRLF. Oct 2, 2017 at 4:13
  • 2
    @OndraŽižka The Windows Editor is still the default associated application for many file extensions, even on Windows 10. Also the 64 KB limit is long gone (since XP or maybe even longer). Besides that, just use \n in your program. If you're using text mode for IO, it will essentially be \r\n on Windows.
    – Mario
    Oct 2, 2017 at 5:52

Preamble: Text is binary with conventions.

"To me it seems that it's safe to use \n only."

"Imagine a company where the originating machine of a content/document can be any platform, and the consuming too. And the way of transferring the documents can be any (mail, shared drive, download,...)"

There are 2 points that we have to address here. If you're serving the file and if you're consuming the file.

Serving the text file:

Stick to a specific format. Define your encoding, your newline policy and keep it consistent along all the files you generate. Understand the specifics of each encoding you decided too use (for example, UTF-8 usually requires you to put a 3-byte BOM at the beginning of each file - some systems are not ready to work with this).

Read about the Turkey Test and why it's important.

Also, as you're a software developer, and not a common user, remember: Text is a bunch of bytes with some specific sprinkled conventions over the top, so treat it as BINARY data and transfer it accordingly on FTP, SFTP, HTTP responses, file writing, etc...

Consuming a text file:

Unless you have the proper specification of the file format, you're going to have a bad time.

But there's nothing stopping you from doing some kind of heuristics about newlines, based on the fact that the most common formats are \r\n, \n and \r, based on Newline Representations on Wikipedia.

What I usually do when I have to consume a text file is searching for \r\n, since it's the most common representation (greater number of platforms). Then skip to using just \n because it's the second most important. Lastly skip to using just \r.

Remember, text is binary data with conventions. Discovering the conventions is what makes it hard.

Final rant:

Text is hard. Handling text the correct way is harder.

There is no such thing as a text file. Also Plain Text is a lie. A final user has the luxury of complaining about TXT files, but we as developers do not.

The sheer number of questions about how to proper detecting encoding on a text file on StackOverflow is a hint.

Just handling common Character Encodings it's difficult due to the sheer amount of different encodings available. Just on that Wikipedia page there are over 60 different to think about.

Handling newlines is just another side of how to proper handle text. Which is special if you have to interface with older devices (such as an Atari-8 that uses 0x9B as newline marker).

Text is binary data with conventions on top.

Important notes:

  • UTF-8 does not require a BOM. The WP article you linked to even says so explicitly, under the "UTF-8" headline. Oct 10, 2017 at 10:54
  • While it's not mandatory, the fact that some major editors like Notepad++ automatically put a BOM unless you explicitly ask it not to, along with Default behavior of UTF-8 encoding on .NET doing the same, makes it almost de-facto standard on UTF-8 files from my point of view. It's not mandatory, and that's the reason I wrote "usually requires", and not "100% mandatory all the time".
    – Machado
    Oct 10, 2017 at 13:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.