Introducing extended line endings support in Notepad

Michel Lopez [MSFT]

For many years, Windows Notepad only supported text documents containing Windows End of Line (EOL) characters – Carriage Return (CR) & Line Feed (LF). This means that Notepad was unable to correctly display the contents of text files created in Unix, Linux and macOS.

For example, here’s a screenshot of Notepad trying to display the contents of a Linux .bashrc text file, which only contains Unix LF EOL characters:

Before

As you can see, Notepad is incorrectly displaying the file’s contents, making the file look garbled. This has been a major annoyance for developers, IT Pros, administrators, and end users throughout the community.

Today, we’re excited to announce that we have fixed this issue!

Starting with the current Windows 10 Insider build, Notepad will support Unix/Linux line endings (LF), Macintosh line endings (CR), and Windows Line endings (CRLF) as usual. New files created within Notepad will use Windows line ending (CRLF) by default, but it will now be possible to view, edit, and print existing files, correctly maintaining the file’s current line ending format.

Here’s a screenshot of the newly updated Notepad displaying the contents of the same Unix/Linux .bashrc file we saw earlier:

After

Also note that the status bar indicates the detected EOL format of the currently open file.

As with any change to a long-established tool, there’s a chance that this new behavior may not work for your scenarios, or you may prefer to disable this new behavior and return to Notepad’s original behavior. To do this, you can change the following registry keys in the following location to tweak how Notepad handles pasting of text, and which EOL character to use when Enter/Return is hit:

[HKEY_CURRENT_USER\Software\Microsoft\Notepad]

Registry

We hope that you find this change useful and look forward to hearing your feedback

5 comments

Discussion is closed. Login to edit/delete existing comments.

  • john_vs@camtechconsultants.com 0

    Do you think this change could have caused this regression in multline textbox behaviour: https://stackoverflow.com/questions/53613746/?

  • BuBu James 1

    Congratulations from China

  • Dave Boltman 0

    Anyone know when this will happen? (Or if it will happen)? It’s more than a year later, and my stock standard notepad.exe on up-to-date Windows 64-bit (v1803, build 17134.950), still does not support this.

    The registry keys mentioned do not exist, and even when I create them, with the “enabled” values (DWORDS), it doesn’t work.

    Did it never make it out of the “Insider” program? Or is this article, or the source info from Microsoft, a hoax?

    • Rich TurnerMicrosoft employee 0

      These improvements to Notepad shipped in Windows 10 1809. Your Windows version of 1803 is not up to date when you posted your question in 19/09. Please update to the latest supported version of Windows 10 (now 1903).

    • Rich TurnerMicrosoft employee 1

      Why would this be a hoax?

      Insider builds are weekly builds of the next version of Windows as it’s being built.

      When the article was posted (May 2018), the Insider builds were previews of 1809 which shipped in Sept 2018.

      At the time you wrote this question you were already almost three versions behind – you were on 1803, but 1809 had already shipped and been replaced by the then current 1903, and 1909 was just about to hit general release.

      Updating registry entries on a version of Windows that doesn’t yet have the corresponding updated executable won’t have any effect.

      If you upgrade to any version of Windows after 1809, Notepad will support *NIX line endings and the ability to load and save UTF-8 encoded text documents.

Feedback usabilla icon