Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've been bugged with this problem for ages and I just tried to ignore it, but when I open files for the first time that was saved from a mac/unix box, I get to see an extra line break after each line:

something like


which is pretty


What I usually do is just do one of the many fixes for this behavior in google, like the TextFX solution to delete all blank lines.

But I am just curious as to why this happens. Why? Why does it not happen again even if I save the file, push it to the git repo(and when it gets edited by another user in a mac/unix) I don't get this problem anymore?


the git problem was a problem I had before but our current problem right now is that we are uploading files using rail's paperclip, which saves it to the file system(we are using a windows machine). when we open the files, we see it as "macintosh" "ansi" even if the server is running on windows. is there a way to make it open it with the proper encoding by default?

share|improve this question
What version are you using? I never had this problem here. Also, what characters show up when "Show All Characters" is enabled? – Aluísio A. S. G. Jun 14 '11 at 8:30
do you have an example file? – James Jun 14 '11 at 9:42
If you select (from the menu) View > Show symbol > Show End of Line, what do you see then? – njd Jun 14 '11 at 9:55
we are using the latest version of notepad++, we just downloaded it and all the files we load are in "macintosh" "ansi" at the lower right corner. We tried the conversion thing to no avail though. the best we could do was to replace all "\r" with a blank space and it worked. we would like to open files like those by default as "windows" "utf8" to avoid the double line this possible? – corroded Jun 14 '11 at 13:54
My guess is that you're getting bit by some file transfer quirk, such as the one described below by Dick. – Daniel R Hicks Apr 22 '12 at 14:48
up vote 6 down vote accepted

I've been struggling with the same issue for several years, but after reading this post and trying some settings in Notepad++ it didn't appear to be Notepad++ that's changing the LF or CR settings.

My 'problem' was caused by a Filezilla setting, with which I download the files from my website to edit them in Notepad++.

In Filezilla I had a lot of extensions in the setting 'Automatic file type classification' (go to Edit > Settings > Transfers > File types). After I cleared them all and re-downloaded my file it opened just fine in Notepad++, no more extra line breaks. Also tested to edit the file, upload it, download and edit it again.

So, in Notepad++ my default setting for new files is:

  • Encoding: ANSI
  • Format: Windows

And in Filezilla the settings are:

  • Transfer type: Auto
  • Automatic file type classifications: extensions list is empty

This solved my problem.

Hope it helps.

share|improve this answer
+1 but for me, I just changed the 'Default transfer type' to Binary. – rybo111 Jun 9 '15 at 20:24

It would help to get some more information like

  1. What editor are you using on Mac/Unix?
  2. When you open it in Notepad++ what does it say in the status bar? Dos/Unix/Mac?
  3. Does it also happen if the file doesn't go through git?

Line endings have been troublesome for a long time when passing files between systems and you can read more about it on Wikipedia. The trouble comes from Windows using CR+LF as line breaks, Mac using only CR and Unix using only LF (I know this isn't a hard and fast rule but in general).

When using an editor expecting a file in Unix format and receiving a file in Windows format the editor can incorrectly interpret the CR+LF as two linebreaks instead of one. It's also common that this shows itself as trailing characters on each line, usually a square or other nonsense.

You should be able to check if this is what's happening to you in Notepad++ by going to View->Show Symbol->Show End of Line. You should also be able to fix this by using the Edit->EOL Conversion function.

It's also possible that this is caused by or can be solved in your git settings. Git has three settings, core.eol, core.safecrlf and core.autocrlf that you can read more about at the git config manpage

share|improve this answer
thanks for the informative response! we tried it in a new installation of notepad++ and like i said in the comments above, we fixed it by replacing "\r" with a blank space. we would like to skip this step though as it is tedious. is this possible? i also added some additional info in the question – corroded Jun 14 '11 at 13:55
I don't know of a way to force Notepad++ to treat it as a specific format so no help there. I think you're problem lies elsewhere though. My guess would be that the file is damaged/malformed causing notepads format detection to fail. Possibly that the file contains "\r \n"(notice the space) instead of "\r\n" or any number of nonstandard combinations. – Pär Björklund Jun 15 '11 at 10:15
i dont think the file is damaged though as opening it in notepad/wordpad doesn't give it the extra lines. – corroded Jun 15 '11 at 14:47

I tried the above solutions and none were working for me, but it did turn out that it was FileZilla though.

I found a recommendation in one of their forums to transfer using binary mode instead of auto. Once I changed this, my problem was solved. :)


Set Transfer type (menu Transfer) from Auto to Binary and upload your script.

share|improve this answer
While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. – Tanner Faulkner May 23 '13 at 17:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .