SFTP is a separate file transfer protocol that runs over SSH, normally on port 22; FTPS is the old FTP protocol with TLS encryption added, using ports 989 and 990 in implicit mode. Both encrypt your files in transit; the real difference is how many ports and certificates each one needs.
The names make these sound like twins. They aren't related at all under the hood. According to the official protocol specs, as of Nov 2026, one is an extension of SSH and the other is an extension of FTP, a protocol whose own spec dates from 1985. Both will move your files securely. Where they differ is plumbing: ports, certificates and how kindly they treat firewalls. Here's the anatomy first, then the catch, then which to pick.
SFTP: file transfer inside SSH
WinSCP's documentation describes the SSH File Transfer Protocol as a network protocol for file access, file transfer and file management over a secure connection, designed by the IETF as an extension of SSH version 2.0. SSH Communications Security's SFTP guide adds that it supports the full security and authentication functionality of SSH, and that like SSH itself it's a client-server protocol.
The port is simple. The SFTP port number is the SSH port 22, and SSH.com describes an SFTP server as basically just an SSH server. On most systems the tooling is already there: OpenSSH, developed by OpenBSD Project developers under a BSD-style licence, ships sftp on the client side and sftp-server on the server side, alongside ssh and scp. WinSCP adds that you don't need shell access to connect to an SFTP server, unlike SCP, though some implementations may still require it.
FTPS: old FTP wrapped in TLS
WinSCP calls FTPS, also known as FTP Secure and FTP-SSL, an extension to FTP that adds support for TLS, the protocol previously known as SSL. The standard behind FTPS is RFC 4217, which describes how FTP clients and servers implement security with TLS, relying on RFC 2246 for TLS and RFC 2228 for the FTP security extensions. It's written in accordance with RFC 959, the File Transfer Protocol itself.
FTPS comes in two flavours, and that's where the ports multiply.
- Explicit FTPS: the client explicitly requests security from the server, then steps up to an agreed encryption method. It's the legacy-compatible method: if a client doesn't ask for security, the server can let it continue unencrypted or refuse it. WinSCP itself requests encryption for both the control and data channels for the whole session.
- Implicit FTPS: no negotiation. The client must open with an encrypted connection or the server should drop it. It was expected to listen on port 990 for the control channel and 989 for the data channel, leaving the original port 21 free for plain FTP.
Anatomy side by side
| SFTP | FTPS | |
|---|---|---|
| Built on | SSH version 2.0 | FTP (RFC 959) plus TLS |
| Standard | IETF design, per WinSCP | RFC 4217 |
| Ports | 22, the SSH port | 990 control and 989 data (implicit); explicit starts on the FTP control port |
| Encryption layer | SSH | TLS, formerly SSL |
| Server identity | SSH host keys | An X.509 server certificate, typically from a public authority |
| Connections | One SSH connection | Separate control and data channels |
The firewall catch
Security isn't the deciding factor for most teams. Firewalls are. FTP was built with two channels, one for commands and one for data, and FTPS inherits that. SSH.com's comparison says FTPS needs complicated firewall configuration and may not work over NAT, that ports 989 and 990 need to be open, and that supporting both active and passive modes further complicates firewall setups. SFTP runs over the standard SSH port, so no extra ports need opening and no separate authentication needs maintaining.
The FTPS standard admits the tension too. RFC 4217 notes that clients sometimes protect the control connection only for part of a session and then revert to plaintext, often because boundary devices such as NAT and firewalls expect to read the control connection to adjust their behaviour. The RFC flags that this has serious security issues. So the very thing that keeps FTPS working through some firewalls weakens it.
Keep in mind who's talking. SSH.com sells SSH products, so its list of SFTP benefits isn't neutral. It also says FTPS has an ASCII mode that can corrupt files if set wrongly and needs an extra server package to install and patch. Those points are worth checking against your own server, but the port and NAT problem is backed by the RFC itself.
Want AI doing the heavy lifting in your marketing?
I build the systems that handle the boring 80 percent, so you get your week back. Done properly, with the human kept in.
Which one to pick
If you control both ends, choose SFTP. One port, keys you probably already manage for SSH, and nothing extra to install on most Linux servers. If you're weighing up a host, it's one of the questions to ask in this guide to choosing a hosting provider.
Choose FTPS when the other side insists on it. Some partners and older systems only speak FTP, and explicit FTPS lets them add TLS without changing much. You'll need a server certificate in place and a firewall team who knows the passive port range. If your files live in managed cloud storage rather than on a server you run, read up on how cloud hosting works first, because you may not need either protocol.
Want your tool on this list? Featured spots and reviews here are paid partnerships. Here's how to partner with me.
Quick answers
Is SFTP the same as FTPS?
No. SFTP is an extension of SSH, while FTPS is FTP with TLS encryption added, defined in RFC 4217.
What port does SFTP use?
SFTP uses the SSH port 22.
What ports does FTPS use?
Implicit FTPS was expected to listen on port 990 for the control channel and 989 for the data channel, leaving port 21 for plain FTP.
Which is easier through a firewall?
SFTP. It runs on the single SSH port, while FTPS needs extra ports open and may not work over NAT, according to SSH.com.
