FTP clients, including those used programatically, allow the user to select ASCII or Binary transfers when uploading a file. Some clients also support some flavor of Auto, where you leave it to the FTP client to decide.

What are some correct reasons to select one format over the other? How does one decide? Besides the clients supporting Auto-detect, how can one automate this decision?

  • Just a comment: automation is probably a bad idea, because at some point it will bite you, and you will spend a long time trying to work out what the problem is. If you do feel ASCII transfer is worth using, stick with enabling it manually when wanted.
    – Alex J
    Commented Jun 3, 2009 at 11:40

6 Answers 6


Windows uses both a carrige return and a line feed to show the end of a line in a text file. Unix generally uses only one (I think a line feed). When you ftp files as text, the ftp program will convert line endings for you. In binary mode the file is transfered exactly as is. So if you are transfering a text document then use ASCII. Anything else and binary is probably your best bet. As others have pointed out, most modern text editors will deal with line endings anyway (Notepad doesn't, nor is it modern :) ) so binary is by far the safer option. I also agree with @njsf, I don't like files being changed behind my back. I have editors that are quite capable of doing a find and replace to fix the line endings if it becomes necessary.


On this day and age, where most text editors automatically detect and adapt to the unix/dos/mac line endings I find very little justification to use ASCII ftp transfers. I always use binary.

I don't like to have the files changed under the covers.

I actually tend to use scp now much more than ftp, and scp just copies the bits...


Always use binary. Do the conversion by hand, if needed -- it's more likely never needed.

ASCII mode does just line-end conversion between systems of different obedience. It's absolutely pointless nowadays. Most editors will adapt, XML parsers mostly ignore them, you only face problems when trying to compile .c files or run sh files on Unix that have MS-DOS line-ending -- but this usually only happens because of a misplaced ASCII mode transfer.

Just say no to ASCII mode. Modern FTP clients will default to BINARY anyway.


Personally, I tend to use binary for every transfer. I was stung once with a file that had been placed from a windows machine onto a unix machine using binary transfer. As a result the txt file still had CR LF endings.

ASCI mode looks at source and dest platforms and performs line-ending translation, so the resultant file I got had CR CR LF line endings (LF was translated by ASCI to CR LF as it was unix -> windows)

Sounds petty - but it was a 20Gb log file, and I only had one time window in which to collect it.

I use eol conversion utils on the local machine if the necessity arises.

EDIT: I was getting the file back onto windows from the unix host


Note that transferring text to some systems is expedited by using the text (not really ASCII) mode because they don't use the character set. For example, EBCDIC on IBM mainframes and similar systems.

As long as both systems use the same base character set, binary is probably less of a hassle.

  • Even then it is probably safer to convert manually, because occasionally the file might have a different encoding or something like that...
    – sleske
    Commented Aug 19, 2009 at 14:54

Understanding what is the way Windows and Unix encode new line in text file, and what is the difference between binary and ASCII transfer mode will let you answer this question by yourself.

  • It's the stated goal of Joel and Jeff to make Stackoverflow (and Serverfault) a Wikipedia-like resource. This means that even though answers may be found all over the internet, it's still worth having this knowledge in the systems here.
    – rcampbell
    Commented Jun 3, 2009 at 12:58

You must log in to answer this question.

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