FTP vs SFTP vs FTPS

FTP: The Plaintext Baseline

FTP (File Transfer Protocol, RFC 959) is the original — and the only one of the three that provides no security. It uses two TCP connections: a control channel on port 21 for commands and responses, and a separate data channel for actual file content. Both channels carry everything in unencrypted plaintext, including the username and password exchanged at the start of every session.

FTP should never be used over the public internet or any network where an attacker could observe traffic. Packet captures of FTP sessions trivially reveal credentials and complete file contents. This is not a theoretical concern — FTP credential harvesting is a documented attack technique used to compromise web hosting accounts. The only contexts where FTP remains acceptable are isolated private networks where physical security guarantees no unauthorized observer, or legacy systems that cannot be upgraded and are air-gapped from any untrusted network.

FTPS: TLS Added to FTP

FTPS (FTP Secure, defined in RFC 4217) adds TLS encryption to the existing FTP protocol. The underlying FTP architecture — dual channels, FTP command set, directory listing conventions — remains unchanged. TLS wraps both the control and data channels to provide encryption and server certificate verification.

FTPS comes in two variants. Explicit FTPS (also called FTPES) starts as a standard FTP connection on port 21. The client sends the AUTH TLS command to signal that it wants to upgrade to TLS, and the server responds with a TLS handshake. After the handshake, the control channel is encrypted. The data channel is secured separately — the client must send PROT P (Protection Private) to require encryption on data transfers; forgetting this step leaves file contents unencrypted even while credentials are protected. Implicit FTPS uses port 990 and assumes TLS from the first byte — there is no plaintext negotiation phase.

FTPS retains FTP's dual-channel complexity. The data channel ports must be open through firewalls, and passive mode port ranges need to be configured on both the server and any intervening firewall. A correctly configured FTPS deployment requires opening port 21 (or 990) plus a range of passive data ports (typically 50000–51000 or similar), and configuring the firewall to allow them. This is significantly more complex than SFTP's single-port design.

SFTP: SSH File Transfer Protocol

SFTP (SSH File Transfer Protocol) is a completely separate protocol from FTP despite the similar name. It was designed as a subsystem of the SSH protocol suite and has no relationship to FTP's command set, port scheme, or dual-channel architecture. SFTP runs over a single encrypted SSH connection on TCP port 22. All file transfer operations — directory listing, upload, download, rename, delete, permission changes — are multiplexed over that single channel as binary SSH protocol messages.

Because SFTP runs over SSH, it inherits all of SSH's security properties automatically: strong encryption (AES-256-GCM, ChaCha20-Poly1305), server host key verification preventing man-in-the-middle attacks, and support for public-key authentication. An SFTP client can authenticate using an SSH key pair — the private key never leaves the client machine, making it resistant to phishing and credential theft in a way that password-based authentication is not.

Firewall configuration for SFTP is simple: open TCP port 22. That single rule covers all SFTP operations. Contrast this with FTPS, which requires port 21 plus a configurable range of passive data ports, each of which must be permitted through every firewall between client and server.

SCP: The Simpler SSH File Copy Tool

SCP (Secure Copy Protocol) is related to SFTP — it also runs over SSH — but it is a simpler, older tool designed for single-file or directory copies rather than interactive file management. The command scp file.txt user@host:/remote/path/ copies a file over SSH with the same security as SFTP. SCP lacks SFTP's interactive features (no directory browsing, no rename, no permission management) but is useful for quick scripted file transfers. Most SSH implementations include scp alongside sftp. For new scripts, sftp or rsync over SSH are generally preferred over scp due to better error handling and resume capability.

Certificate Management: FTPS vs SFTP

FTPS requires a TLS certificate on the server — the same kind of X.509 certificate used by HTTPS. This certificate must be signed by a certificate authority trusted by the client (or the client must be configured to trust the specific certificate). Certificates expire and must be renewed, typically annually. For an internal FTPS server, you may need to set up a private CA or distribute the server's self-signed certificate to all clients. Misconfigured FTPS clients that accept invalid or expired certificates provide no man-in-the-middle protection despite the TLS layer being present.

SFTP uses SSH host keys instead of X.509 certificates. The first time a client connects, it stores the server's public host key in ~/.ssh/known_hosts and verifies it on all subsequent connections. There are no expiry dates, no certificate authorities, and no renewal process. SSH host keys persist indefinitely until you explicitly rotate them. For most deployments, this simpler trust model is an advantage over FTPS's certificate management overhead.

Which to Choose

For any new deployment, choose SFTP. It is secure by default (all traffic is always encrypted), requires only one open port, uses SSH key authentication, and is supported by every major FTP client including FileZilla, WinSCP, and Cyberduck. If you already have an SSH server running (which most Linux servers do), SFTP requires no additional software — just enable the SFTP subsystem in the SSH server configuration.

Choose FTPS only when you have a specific requirement for it: a legacy partner system that only supports FTPS, a compliance requirement that mandates TLS certificates rather than SSH keys, or an existing FTP infrastructure that you are upgrading incrementally. If you must use FTPS, use explicit FTPS on port 21, require TLS on the data channel (PROT P), and verify server certificates. Never use plain FTP over an untrusted network under any circumstances.

FTP vs FTPS vs SFTP Compared

Frequently Asked Questions

Is SFTP the same as FTP over SSH?

SFTP runs over SSH but it is not simply FTP tunneled through an SSH connection. SFTP (SSH File Transfer Protocol) is a completely separate protocol defined in the SSH protocol suite. It has its own command set, its own packet format, and its own semantics — it shares nothing with the FTP command set beyond the general concept of file transfer. The name similarity is misleading. When someone says "FTP over SSH" they sometimes mean SFTP, but technically you could also tunnel plain FTP through an SSH port forward — that is different from SFTP.

What is the difference between FTPS explicit and implicit?

Explicit FTPS (also called FTPES) starts as a plain FTP connection on port 21 and upgrades to TLS when the client sends the AUTH TLS command. The server can choose whether to require TLS or allow plaintext. Implicit FTPS assumes TLS from the first byte of the connection and uses port 990 by default. Implicit mode was declared obsolete by RFC 4217 but is still widely supported by servers and clients. Explicit FTPS on port 21 is the current standard and is what most FTPS deployments use. Both modes encrypt the control and data channels once TLS is established.

Which is more secure, SFTP or FTPS?

Both SFTP and FTPS provide strong encryption and are secure when correctly configured. SFTP uses SSH encryption (AES, ChaCha20) and can use SSH public-key authentication, which is phishing-resistant and not vulnerable to password brute force. FTPS uses TLS (the same encryption as HTTPS) and requires certificate management. In practice, SFTP is considered simpler to secure correctly because it uses a single port, integrates with existing SSH key infrastructure, and has fewer configuration paths that can leave data exposed. FTPS misconfiguration — particularly failing to require TLS on the data channel — can inadvertently leave file content unencrypted.

What port does SFTP use?

SFTP uses TCP port 22 — the same port as SSH, because SFTP is a subsystem of the SSH protocol. There is no separate SFTP port. When an SSH server receives a connection on port 22, the SSH handshake determines whether the session will be a terminal session, an SFTP session, or another SSH subsystem. This single-port design is a major operational advantage over FTP and FTPS, which require multiple ports for control and data channels.

Can I use FileZilla for SFTP and FTPS?

Yes. FileZilla supports plain FTP, explicit FTPS, implicit FTPS, and SFTP in a single client. When creating a new site in FileZilla's Site Manager, select the protocol from the dropdown: FTP for plain FTP, FTP with explicit TLS for FTPES, FTP with implicit TLS for implicit FTPS, and SFTP for SSH-based file transfer. FileZilla also supports SSH key authentication for SFTP connections — go to Edit > Settings > SFTP to add your private key. WinSCP is another popular client that supports all three protocols.

Should I use FTP, SFTP, or FTPS for my web hosting?

For web hosting, use SFTP if your host supports it — it is the simplest and most secure option. Most Linux-based hosts run an SSH server on port 22 and can enable SFTP access with no additional software. If your host only offers FTPS, use explicit FTPS (FTPES) with certificate verification enabled. Never use plain FTP for production web hosting — your login credentials and website files travel unencrypted, exposing your site to credential theft and content interception. If you are evaluating hosting providers, SFTP support is a basic security requirement.