You might be wondering how the inner workings of various file transfer protocols differ, and we're here to provide you with just that information. By distinguishing the components of the three, we can outline the benefits of using one protocol over the others.

If it's history you're interested in, scroll down, or explore File Transfers In The Age Of Sorcery.

FTP vs SFTP vs FTPS: quick answer

FTP is the original file transfer protocol and it does not encrypt traffic, so usernames, passwords, commands, and file data can travel in clear text.

FTPS is FTP with SSL/TLS encryption added, but it keeps FTP’s two-connection design, so it still has the same “ports, firewalls, and NAT” complications, plus certificates.

SFTP is a different protocol from FTP and FTPS. It runs over SSH, uses one connection, and encrypts both commands and data by default.

SFTP vs FTP vs FTPS: what sets them apart

Before we get into their history and inner workings, here's a full feature comparison for those of you who're just here for the final answer. Read our performance benchmarks for SFTP vs. FTPS.

Ports and connections

    • FTP: Two connections (control + data), control usually TCP 21.
    • FTPS: Same two-connection design, explicit usually TCP 21, implicit often TCP 990.
    • SFTP: One connection, typically TCP 22.

Authentication

    • FTP: Username/password, may allow anonymous access.
    • FTPS: Username/password, can also use TLS client certificates, may allow anonymous access.
    • SFTP: Usually SSH keys, can also use username/password (encrypted).

Encryption

    • FTP: None by default, credentials and data can travel in clear text.
    • FTPS: TLS encryption, but must be enforced for both control and data channels.
    • SFTP: Encrypted by default via SSH (commands and data).

File management

    • FTP: Basic transfer and directory listing.
    • FTPS: Similar to FTP.
    • SFTP: Similar core commands, often richer filesystem operations (permissions, ownership) depending on server settings.

Common trouble spots

    • FTP: Firewalls and NAT, passive ports, clear text exposure.
    • FTPS: Same firewall and passive port issues, plus certificate expiry and misconfiguration.
    • SFTP: Key sprawl, shared keys, overbroad permissions.

What's FTP and how did it start?

File Transfer Protocol has been around the block since the early 1970s. It was created as one of the first two application layer network protocols (the other one being Telnet) to facilitate file transfer between hosts over the ARPANET Network Control Program (NCP), the internet’s granddaddy.

FTP was initially designed to work on top of NCP, a simplex protocol, meaning that communication travels one-way per connection, requiring two ports for two-way communication, from the client to the server and back. What a pain!

First, the client connects to the server and then, following a successful authentication, the server connects back to the client. TCP/IP, NCP’s successor, is a duplex protocol and allows for two-way communication over a single port. However, when FTP was ported to work on top of TCP/IP, it was never altered to use just one port, for the sake of backward compatibility.

At the dawn of computer networking, security wasn't really on the minds of FTP’s creators. So, naturally, it was never designed to be a secure protocol. It doesn't encrypt any of its traffic, so therefore, usernames, passwords, commands and file data are all passed in clear text, allowing anyone to capture or alter these packets over the network.

In addition, the use of two ports, as mentioned above, is problematic when the client is behind firewalls and NATs, where they have a local IP address that isn’t even exposed to the public network, the server has no means to connect back to the client. There are two possible approaches that can be taken to solve this issue, the popular choice being the “Passive” mode, where the client opens both connections to the server.

Despite its faults, FTP was a great way to share files throughout the years, long before HTTP or even TCP/IP were invented. It facilitated sharing, uploading and downloading files with simple and optional means of authentication, user and password.

The birth of FTPS

In the 1990s, thanks to the internet, a much broader population obtained access to files on FTP servers from all over the world, which also meant that data traversed longer paths, creating more opportunities for third parties to eavesdrop on non-encrypted data transmissions.

As a solution to this problem, in 1994, Netscape released the application layer wrapper known as Secure Sockets Layer or SSL. This allowed applications to communicate over a network in a secure, private fashion and to this day, we all use it with the HTTPS protocol. The SSL protocol was also applied to FTP and so an extension to FTP was born, FTPS.

There are two methods in which to invoke client security with FTPS:

  • Implicit FTPS: The entire session is encrypted using SSL (or later, TLS) encryption. If the client doesn’t immediately make the security request, the server is expected to drop the connection. This limitation is the reason that implicit FTPS is generally considered deprecated.
  • Explicit FTPS: A traditional FTP connection is established and once the connection is made, right before authentication, a secure SSL/TLS connection is established. Unlike implicit FTPS, if the client doesn’t make the security request, it is up to the server to either decline the connection or continue with basic FTP. The client can also choose whether or not to encrypt the data channel (keep in mind that there are 2 ports used with FTP). The server again can choose whether to allow or prohibit insecure requests.

SFTP

SFTP, Secure File Transfer Protocol, or SSH File Transfer Protocol, is the youngest protocol and yet, it’s been around since the late 1990s. As opposed to FTPS, it’s not an extension to FTP. It was built from the ground up. It uses just one port and the protocol itself doesn’t provide authentication or security but rather expects the underlying protocol, SSH, to provide this.

We won’t go into all the details, but SSH, or Secure Shell, is the cryptographic protocol used to secure network connections over an unsecured network and is also used to login to remote servers and to forward or tunnel ports. SSH uses public-key cryptography to authenticate users and machines, but it also supports username/password authentication (which are also encrypted if used).

Since SFTP shares the default port (22) with other SSH services, it’s usually bundled with the SSH server implementation, meaning that it’s built-in with any Linux machine.

The basic commands used in SFTP are the same as in FTP or FTPS (i.e. ls, get, put) but there are also some differences. For instance, the SFTP response when listing files is more consistent and contains more details, SFTP allows file system operations that FTP does not (like changing permissions and file ownership).

The default choice for secure file transfer nowadays is SFTP because of its superior security and its vast distribution as part of the Linux operating system. If you're interested in comparing performace, check out our SFTP vs. FTPS Benchmarks.

Quick recap: FTP vs FTPS vs SFTP

FTP is the original file transfer protocol. It is still common, but it was designed for a time when encryption was not assumed, so it is best treated as a legacy option unless the network is tightly controlled.

FTPS keeps FTP’s familiar behaviour and adds TLS. It can be secure, but it also adds moving parts: encryption rules must be enforced properly and certificates must be maintained, or the whole setup becomes unreliable.

SFTP is not FTP with security added. It is a separate protocol built on SSH, usually with one port and encryption as the default state. In practice, it tends to be easier to run securely day to day, as long as SSH keys and permissions are managed sensibly.

Choosing between FTP, FTPS, and SFTP

FTP is the baseline that refuses to die. It is widely supported and familiar, but it was never built for privacy, so it shouldn’t be treated as a safe default on modern networks.

FTPS takes FTP and adds TLS. That can give you strong encryption, but it doesn’t simplify the underlying design. You still have the two-connection model to contend with, and you add certificate lifecycle to the list of things that can break transfers without warning.

SFTP is the secure clean break. It’s a separate protocol built on SSH, usually running over a single connection with encryption as the normal state. When people say they want “secure file transfer,” this is typically what they mean in practice.

For most business and compliance-sensitive use cases, SFTP is the sensible default. Use FTPS when a vendor dictates it or when your organisation already runs certificate management as a disciplined routine. Treat plain FTP as a legacy exception, and keep it on a short leash with clear constraints and a migration plan.

SFTP To Go allows you to instantly set up encrypted cloud storage with SFTP, FTPS and Amazon S3 protocol support.

FAQ: FTP vs SFTP vs FTPS

What is the difference between FTP, SFTP, and FTPS?

FTP is the original File Transfer Protocol and does not encrypt traffic by default. FTPS is FTP with TLS encryption added, but it keeps FTP’s separate control and data connections. SFTP is a different protocol that runs over SSH, typically using a single encrypted connection for both commands and file data.

Is SFTP the same as FTPS?

No. SFTP runs over SSH and is a separate protocol from FTP. FTPS is FTP with TLS added. They are secured in different ways, use different connection models, and are configured differently in clients and servers.

Is FTP secure for sensitive or regulated data?

Not by default. FTP does not encrypt usernames, passwords, commands, or file contents unless it is wrapped in additional protections outside the protocol. For secure file transfer in business, compliance, and cloud environments, plain FTP is generally treated as a legacy exception rather than a safe default.

Which ports do FTP, FTPS, and SFTP use?

Ports vary by configuration, but the common defaults are:

  • FTP: Control channel typically uses TCP 21, with a separate data connection (active or passive).
  • FTPS: Explicit FTPS typically starts on TCP 21, implicit FTPS commonly uses TCP 990, and it still uses a separate data connection.
  • SFTP: Typically uses TCP 22 and usually runs as a single encrypted connection.
What is the difference between explicit FTPS and implicit FTPS?

Explicit FTPS starts as a standard FTP connection and then upgrades to TLS before authentication. Implicit FTPS expects TLS from the first packet and commonly uses a different port. In modern deployments, explicit FTPS is more common because it is generally more flexible across clients and server policies.

Why does FTP and FTPS struggle with firewalls and NAT?

FTP and FTPS use separate control and data connections. In passive mode, the server opens a data port from a defined range and the client connects to it, which means firewalls must allow that passive port range. In active mode, the server connects back to the client for data, which often fails behind NAT or strict inbound firewall rules.

What authentication methods do SFTP and FTPS support?

Both can support strong authentication, but they do it differently:

  • SFTP: Commonly uses SSH key authentication, and can also use username and password (encrypted in transit).
  • FTPS: Commonly uses username and password, and can also use TLS client certificates in some setups.
Which is better in 2026 for secure file transfer and compliance, SFTP or FTPS?

Both can be secure, but the practical difference is consistency. SFTP is encrypted by default and typically uses a single connection, which reduces configuration drift. FTPS can provide strong TLS encryption, but security depends on enforcing encryption for both control and data channels, and reliability depends on disciplined certificate lifecycle management. The best choice depends on vendor requirements, operating model, and how authentication and access control are managed.