Cloud Parts

FTP

The File Transfer Protocol: text commands on a control connection to port 21, and a second TCP connection for every listing or file. Everything, passwords included, travels unencrypted.

What it is
Network protocols (file transfer protocols)
Type
Open source
Made by
IETF
License
Open standard (IETF RFC)
Facts checked
8 October 2026
Website

What it is

An FTP client opens a TCP connection to the server’s port 21 and holds a conversation in Telnet-style text lines: USER and PASS to log in, CWD to change directory, TYPE A or TYPE I for text or binary, LIST for a directory listing, RETR to download and STOR to upload, each answered with a three-digit reply code. The files themselves never cross that control connection. For every transfer a separate data connection is opened. In active mode the client announces an address and port with PORT and the server connects back to it, by default from its port 20. In passive mode the client sends PASV, the server replies with an address and port it is listening on, and the client connects out to it. Passive mode gets through firewalls more easily because the client makes both connections outward, so clients such as curl use it by default. EPRT and EPSV (RFC 2428) extend both to IPv6.

In ASCII mode the sender converts text to a standard form with CRLF line endings and the receiver converts it to its own, which damages a binary file sent that way; image mode (TYPE I) sends bytes untouched. Standard FTP sends all data and control information, including passwords, unencrypted, and an FTP server can be told with PORT to connect to a third machine, the basis of the “bounce attack”. FTPS (FTP over TLS) adds encryption to the same protocol; SFTP, despite its name, is a different protocol that runs over SSH. Chrome 88 removed FTP support from the browser entirely.

Why teams pick it

  • Easy to script: command-line tools such as curl speak FTP and FTPS, and a transfer is a few text commands
  • One login covers a whole session: list, upload and download many files, restart an interrupted transfer (REST) or abort one (ABOR)
  • Anonymous FTP made public archives easy: anyone can log in as anonymous and download

Watch out for

  • No encryption: user names, passwords and file contents cross the network in plain text
  • The second connection on a negotiated port is awkward for firewalls and NAT; active mode often fails outright from behind them
  • ASCII mode changes line endings, so a binary file sent as text arrives corrupted
  • Weak by design against abuse: PORT enables bounce attacks, and the base standard allows unlimited password guesses
  • Browsers no longer support it: Chrome removed FTP in version 88

The FTP family

1 technologies built from or on FTP

Alternatives

What all file transfer protocols have in common →
SFTPOpen sourceThe SSH File Transfer Protocol: binary file-system requests (open, read, write, list, rename) carried inside an encrypted SSH session on port 22. Not FTP, and never finished as an RFC.

How it fits with other technologies

Anonymous FTP from the command line with curl (passive mode by default) · bash

# list a directory on the GNU project’s public FTP server
curl -s --list-only ftp://ftp.gnu.org/gnu/hello/ | tail -2
# hello-2.9.tar.gz
# hello-2.9.tar.gz.sig

# download one file (curl logs in as anonymous and uses binary mode)
curl -O ftp://ftp.gnu.org/gnu/hello/hello-2.9.tar.gz

See it in a real stack

No architecture uses FTP yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from1971–2005

FTP is older than TCP. In April 1971 Abhay Bhushan at MIT Project MAC proposed a File Transfer Protocol (RFC 114) so that users could work with the file systems of other ARPANET hosts without logging in to them, starting with MIT’s Multics and ITS machines. A long series of RFCs revised it through the 1970s, and when the ARPANET moved from NCP to TCP, FTP was rebuilt for TCP as RFC 765. Jon Postel and Joyce Reynolds’s RFC 959 (October 1985) corrected and extended that edition, adding commands such as MKD, PWD and CDUP, and has been the base specification ever since.

Anonymous FTP archive sites, open to anyone who logged in as anonymous, offered a wealth of public software and documents; RFC 1635 (1994) explained how to use them. The protocol’s design then aged badly. Firewalls blocked the server’s connection back to the client, so RFC 1579 (1994) recommended that clients use PASV. RFC 2577 (1999) documented the bounce attack and password guessing, and noted that standard FTP sends everything unencrypted. Security was added on top as FTPS rather than changed in FTP itself, and browsers eventually dropped the protocol.

Why it’s built this way

Separate control and data connections
Commands and replies stay on one connection while each file flows on its own, so a client can keep talking to the server, list directories and start or abort transfers independently of the data.
The server connects back by default
In RFC 959 the server initiates the data connection to a port the user side listens on. That worked while hosts could reach each other directly, and became FTP’s main problem once packet-filtering firewalls blocked incoming calls to unknown ports, which is why RFC 1579 told clients to use passive mode.
Text commands and transfer types
Hosts on the network stored text differently (RFC 959 still defines both ASCII and EBCDIC types), so FTP defined a standard text form that each side converts to and from, plus an image type for raw bytes.

Timeline

  1. 1971

    RFC 114 proposes a File Transfer Protocol at MIT

  2. 1985

    RFC 959, the current FTP specification

  3. 1994

    RFC 1579 recommends passive mode for firewalls; RFC 1635 explains anonymous FTP

  4. 1998

    RFC 2428 adds EPRT and EPSV for IPv6

  5. 1999

    RFC 2577 documents bounce attacks and other security problems

  6. 2005

    RFC 4217 standardises FTP over TLS

Sources7 · facts checked 8 October 2026

Improve this page on GitHub