ASCII vs Binary

FTP supports two transfer types:

ASCII (TYPE A): text mode. Server may convert line endings on transfer:

• Unix → Windows: LF → CRLF.
• Windows → Unix: CRLF → LF.

Binary (TYPE I): image mode. Bytes transferred verbatim. Used for everything except plain text.

C: TYPE I
S: 200 Type set to I
C: RETR photo.jpg
[binary stream, no modification]

Defaults vary; modern client default is Binary. ASCII for legacy compatibility.

Other types:

• TYPE E: EBCDIC (mainframe character set).
• TYPE L 8: 8-bit local byte size (functionally same as binary on most systems).

Modes (MODE):

• S (Stream): bytes flow continuously (default; nearly always used).
• B (Block): structured blocks with markers.
• C (Compressed): RLE compression.

Structures (STRU):

• F (File): sequence of bytes (default).
• R (Record): sequence of records.
• P (Page): random-access pages.

In practice, only TYPE I + MODE S + STRU F is used universally. Other combinations are vestigial.

Modern FTP servers may not support TYPE A line conversion correctly. Many problems are solved by always using TYPE I.

Why is this in the protocol? FTP comes from a heterogeneous era: mainframes used EBCDIC, different line endings, different byte sizes. The protocol abstracts these differences.

Today, almost all transfers are binary across UTF-8 systems with LF or CRLF — far simpler than FTP's design assumes.