SFTP vs FTP vs FTPS: what's the difference, and which to use

23 August 2026

The short answer to SFTP vs FTPS: both encrypt your files and passwords, and plain FTP encrypts nothing. SFTP is a separate protocol that runs inside SSH, uses a single connection (normally port 22) and authenticates with SSH keys. FTPS is the original FTP with TLS added, keeps FTP's separate control and data connections, and is harder to get through firewalls. If you control the server, use SFTP. Use FTPS when the server or a partner only offers the FTP family. Use plain FTP only for public downloads or on a network you trust completely.

The rest of this post explains why, so you can make the call for your own setup.

The three at a glance

FTP: the original, and why it leaks

FTP dates from the 1970s and was last fully specified in RFC 959. A session is a text conversation on the control connection:

220 Service ready
USER deploy
331 Password required
PASS correct-horse-battery
230 Logged in
EPSV
229 Entering Extended Passive Mode (|||50123|)
RETR index.html

Everything above, including the password, crosses the network as readable text. So does the file. Anyone on the path (a shared Wi-Fi network, a compromised router) can read both.

FTP also opens a second connection for every listing and file. In active mode the server connects back to the client, which rarely works through home or office NAT. In passive mode the client connects to a port the server announces in its PASV or EPSV reply. Firewalls cope with plain FTP by reading the control channel and opening that port on the fly.

FTPS: FTP with TLS around it

FTPS keeps all of FTP's commands and wraps them in TLS, the same encryption HTTPS uses. There are two ways to start the session. Explicit FTPS connects to port 21 in the clear and upgrades with the AUTH TLS command. Implicit FTPS starts TLS immediately, conventionally on port 990. We compare them in detail in FTPS explicit vs implicit.

Two details decide whether FTPS is actually secure:

• The data channel. After login, the client must send PBSZ 0 and PROT P to encrypt the data connections too. Without PROT P, the password is protected but file contents cross in the clear.
• The certificate. The server proves its identity with a TLS certificate, checked against the hostname just like a website. Internal servers often use self-signed certificates, which means the client either fails or has to be told to skip the check.

FTPS's real cost is the firewall. Because the control channel is encrypted, firewalls and NAT gateways can no longer read the passive-mode reply to open the data port. The server has to be configured with a fixed range of passive ports, that range opened on every firewall in between, and often its public address set explicitly so it advertises something reachable.

SFTP: a different protocol with a similar name

SFTP is not FTP over SSH. It is the SSH File Transfer Protocol, a binary protocol that runs as a subsystem inside an SSH connection. It was developed as a series of IETF drafts (draft-ietf-secsh-filexfer) and never became an RFC, but version 3, the one OpenSSH implements, is supported almost everywhere.

Because it rides on SSH, SFTP inherits SSH's strengths. There is one TCP connection, so one firewall rule. Servers are identified by host keys, verified on first connection and pinned after that. Logins can use public keys, which cannot be phished the way a password can, and keyboard-interactive prompts for one-time codes.

An OpenSSH server can also offer SFTP without offering a shell, which is the usual way to give a deployment account file access and nothing more:

Subsystem sftp internal-sftp

Match User deploy
    ChrootDirectory /srv/sftp/%u
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no

The chroot directory must be owned by root and not writable by anyone else, or sshd refuses the login. See sshd_config for the details.

A note on SCP: since OpenSSH 9.0 the scp command uses the SFTP protocol underneath by default, so modern SCP and SFTP share the same server-side code.

SFTP vs FTPS: how to choose

• You run the server: SFTP. It is already there if the machine has SSH, it needs one port, and keys are better than passwords.
• Shared hosting: use SFTP if the control panel offers it. Many hosts offer both, and SFTP avoids passive-port trouble.
• A partner or legacy system dictates FTPS: use it, insist on PROT P and a valid certificate, and agree the passive port range up front.
• Plain FTP: only for anonymous public downloads, or inside a network you fully trust. Never for credentials that also work elsewhere.

Both SFTP and FTPS give you encryption in transit. The difference is mostly operational: SFTP is simpler to run and to firewall, and FTPS fits better where X.509 certificates are already how identities are managed.

Using all three from one Mac app

You do not need a different tool per protocol. Wharf's site editor has a Protocol picker with SFTP, FTP, FTPS (explicit), FTPS (implicit) and Amazon S3, and it fills in the usual port (22, 21 or 990) when you change it.

For FTPS, Wharf sends PBSZ 0 and PROT P after login and stops with an error if the server will not protect the data channel, rather than carrying on half-encrypted. It checks the certificate against the hostname. For a server you control with a self-signed certificate, Allow untrusted certificate under Advanced turns that check off for that one site (see when allowing one is safe). Data connections are passive, trying EPSV first and falling back to PASV. With PASV, Wharf connects to the host you entered and ignores the address the server advertises, which is often a private address behind NAT.

When an FTP server misbehaves, View › Server Log… (⌘⇧K) shows the full command and reply transcript with passwords already redacted. The support page asks for it in FTP bug reports, and the features overview covers the rest.