Introducing extended line endings support in Notepad

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:


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:


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:



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

Comments (27)

  1. Sertelegger says:

    Now if you could also add the ability to enable both Status Bar AND Word Wrap at the same time I’d call Notepad complete 😀

    1. You can now use the Status Bar setting, regardless of the Word Wrap setting.

      1. Have you tried it? When I enable word wrap, the status bar menu item is disabled.

        1. Have you updated your system, as this is currently an Insider feature?

      2. Now I’m just missing vi keys.

      3. SammyKrosoft says:

        Ok thanks my good Michel, then I’ll call it Notepad Complete too, now 🙂

    2. Looking back at the Unicode Newline Guidlines, I wish that they assigned modal interpretations to LF and CRLF instead of inventing ‘LINE SEPARATOR’ (U+2028) and ‘PARAGRAPH SEPARATOR’ (U+2029). Back then, it wouldn’t have been too far-fetch to imagine LF and CRLF being assigned those semantics, respectively. If CRLF added just a little more vertical space, you could have a natural “paragraph mode”., with LF working as hard wrap. Being able to more easily distinguish wrapped lines from EOL-delimited lines would be nice regardless. We could have had ↵ and ¶ in notepad, and plain text would be just slightly less plain.

      Oh well. My niece isn’t getting a pony, and won’t be getting mine. 😄

  2. Tom_Befrugal says:

    Can we finally have custom tab sizes, so we no longer have to see tab sizes that are 8 characters long?

  3. Eug48 says:

    Thank you, this is great. Small things often make a big difference! #BetterLateThanNever

  4. “Macintosh line endings (CR)” is unfortunately misleading. CR was the EOL for old Mac OS before OS X, meaning it hasn’t been the default Mac EOL for almost 17 years. Since OS X, Mac also uses LF as EOL. I hope the menu doesn’t call CR the Mac line ending, because then people will start sending CR files to Mac users, which is pointless.

    1. You are right but we needed to keep it simple.

  5. Spiffyk says:

    Will it also use UTF-8 by default like any sane editor of the 21st century would?

  6. When working with unix EOL delimeters, do other unix conventions apply? Is LF treated as a line separator or a line terminator? The line separator convention is at odds with much software with a unix background, resulting in “unterminated line” warnings and spurious modifications. Is the UTF-8 BOM still considered the norm for these files? Would it be automatically added when saving?

  7. Snnnap59 says:

    Does this version of Notepad have wrap-around search and replace now, where if you hit the last match for your search at the bottom of the file, search goes back to the first match at the top of the file?

  8. lyderis-it says:

    OMG… what an achevment after 20 years!!! So now we will wait for the next 20 years for saving seetings: default UNIOCDE, view status bar, etc…

  9. C Shark says:

    This is really great, thank you!
    To make it even more useful, why not add a little code to allow selection of the output format regardless of the original.
    (for example) I copy/paste something into Notepad (which I do all the time…) and I want to use that file in Unix format.
    It would be really useful to select “Save with NL Separaters”)

    NOT that I’m not really grateful for what you’ve done; thanks a lot!


  10. fabbiann says:

    In the furute support programming language?

    1. You can use VS Code for that.

  11. Alessio T says:

    a lil… late?

    1. Better late than never?

  12. cheong00 says:

    Yay! This is really wanted for a long time.

    Btw, since Notepad is mostly an application with very large edit control, does it mean all applications that use multiline edit control will get a free ride to this “extended line endings support” in this version of Windows, or is that a Notepad specific one?

    1. This is an update to the edit control. Stay tune for more news about this.

  13. cheong00 says:

    Also, I’d like to ask what happens if fWindowsOnlyEOL is in default setting, and I open a file with mixed EOL, say, manually edited XML file that was machine generated.

    1. It will apply the logic based on the ending detected on the first line.

  14. Will it be published also as a separate download till the next Windows 10 release?

    1. This is an Insider feature (RS5)

  15. Besides the EOL difference, The “UTF-8” encoding in Notepad is also not *nix flavor. Notepad uses “UTF-8 with BOM”, but *nix uses “UTF-8 without BOM”. Prepending a BOM makes UTF-8 hard to work with some ASCII-only programs and hard to concatenate using the “cat file1.txt file2.txt” command. So I think it’d be better if Notepad is going to support “UTF-8 without BOM” sooner.
    Also it’d be better if we could reconfigure the default encoding as not ANSI. — Even by a registry key is better than no way.

Skip to main content