Why do we have both FTP and SFTP, and what is the difference?

2180 words Human made

Published 2026-05-18 06:29:48.821605 by Carsten Blum

As the founder of ftpGrid both the historical and technical difference of FTP and SFTP is second nature to me, but I often hear the terms used interchangeably and as synonymes. Throw FTPS in the mix, and the confusion is understandably complete. In this article I'm going to highlight the difference between primarily FTP and SFTP, but also touch on FTPS. Fun fact, might be playing it fast and loose with the word fun here, I wrote my thesis on FTP and implemented a version of FTP in C to be used in embedded IoT devices.

I'm not going to turn this in to a long "back when I was a kid" story, but let's start at the beginning, before I was even born.

Why do we have both FTP and SFTP?

A historical background

FTP

FTP was the brainchild of Abhay Bhushan and initially suggested as a new protocol for transferring files in RFC 114 on 16th of April 1971. In the introduction he writes:

The extended file transfer protocol would facilitate the exchange of programs and data between computers, the use of storage and file handling capabilities of other computers

Since 1971, the protocol has been extended many many times. For instance RFC 3659 in 2007 which introduced the "Machine Processing" extensions like MLSD commands.

SFTP

SFTP on the other hand, not to be confused with "Simple File Transfer Protocol" which was only a RFC draft, is a set of commands used in Secure Shell Protocol (SSH). SSH was first introduced by Finnish computer scientist Tatu Ylönen in 1995. Initially, and still today, SSH was actually a secure replacement for rsh and rlogin. In other words, it had nothing todo with transferring files between hosts. Then in 1997 the Internet Engineering Task Force (IETF) proposed an actual replacement for the classic FTP called SSH File Transfer Protocol, or Secure File Transfer Protocol - SFTP.

An important point here is that, SFTP is not "FTP over SSH", it is a completely isolated protocol from FTP.

FTPS

Then what is FTPS? Well now we circle back to the original FTP protocol. FTPS is also know as FTP Secure or FTP-SSL and adds support for the Transport Layer Security (TLS). This is completely identical to how HTTP is a plain text protocol, but HTTPS adds TLS support, and is now considered secure. We have Netscape - the original developer of Mozilla, now Firefox - to thank for SSL and TLS. They wanted to make a secure version of HTTP, but instead of just inventing something completely new, they invented the application layer wrapper, Secure Sockets Layer. SSL is obsolete now and replaced by TLS. But the design lives on. The point of the application layer wrapper is that you can basically add encryption to any text protocol.

Implicit

Just to add a little confusion on top of FTPS - that are actually two modes of operation - implicit and explicit. Implicit is the older legacy version, where the client will actually connect to port 990 and immediately establish the TLS connection. This is a bit of a mess.

Explicit

The explicit version of FTPS is where the connection is initially established as regular FTP, the client then sendes a AUTH TLS, asking the server to use TLS and encrypt the connection. ftpGrid only supports explicit FTPS and explicit is considered the modern version.

Technical insight

So with the history in place, what does this technically mean for you?

At the highest level:

FTP is the original file transfer protocol
FTPS is classic FTP with TLS encryption added
SFTP is an entirely different protocol built on SSH

While they all solve the same business problem — transferring files between systems — they do so in very different ways technically and operationally.

FTP - simple and universally supported

Classic FTP is still everywhere.

The reason is simple:

Almost every operating system, ERP system, camera, industrial machine and legacy platform on earth supports FTP.

FTP is:

Mature
Extremely widely supported
Fast
Easy to automate

The downside is equally obvious:

Classic FTP is plain text.

This means:

Usernames are unencrypted
Passwords are unencrypted
File transfers are unencrypted

This was perfectly acceptable in 1971. In 2026... less so.

Still, FTP absolutely still has legitimate use cases:

Internal isolated networks
Legacy integrations
Embedded devices
Air-gapped environments
Extremely old industrial systems

This is one of the reasons why we recently launched our dedicated Cloud FTP platform and content cluster. FTP remains deeply integrated into modern infrastructure, even if many developers pretend otherwise.

FTPS - secure FTP without changing the protocol

FTPS solves the biggest weakness of FTP:

Encryption.

Technically, FTPS is still FTP.

This means:

Same commands
Same workflows
Same directory semantics
Same client behavior

The only major difference is that the traffic is encrypted using TLS.

This is incredibly important operationally because many existing systems already understand FTP. Adding TLS support often requires little or no workflow redesign.

For example:

ERP exports
Banking integrations
Surveillance systems
Industrial automation

...often continue working almost unchanged when moving from FTP to FTPS.

This is also why FTPS remains extremely common in enterprise environments.

Why FTPS can become operationally difficult

FTPS inherits both the strengths and weaknesses of FTP.

One of the biggest technical quirks is the dual-channel architecture.

FTP historically uses:

A control connection
A separate data connection

Once TLS encryption gets involved, firewalls and NAT suddenly become much more complicated.

This is why FTPS sometimes causes headaches with:

Firewalls
Passive mode
Load balancers
Deep packet inspection
Enterprise proxies

Especially in highly locked-down enterprise environments.

That said:

Modern explicit FTPS works remarkably well when configured correctly.

SFTP - a completely different architecture

SFTP is operationally much cleaner.

Because it runs entirely inside SSH, it uses:

One connection
One port
One encrypted tunnel

This dramatically simplifies networking.

In practice, SFTP is often easier to:

Secure
Audit
Firewall
Route
Deploy in cloud infrastructure

This simplicity is one of the reasons SFTP has become the de-facto standard for secure file transfers in modern cloud environments.

And unlike FTP/FTPS, SFTP was designed with security from the beginning. You can read more about using SFTP with ftpGrid here.

SFTP is not "better FTP"

This is probably the single biggest misconception.

SFTP is not:

FTP version 2
FTP over SSH
"secure FTP"

SFTP is an entirely different protocol with a completely different architecture.

The only thing FTP and SFTP really share is:

The business purpose.

This distinction matters because FTP and SFTP often behave differently regarding:

Permissions
Symbolic links
Directory handling
Metadata
File locking
Automation behavior

This becomes especially important in enterprise integrations and automation workflows.

So when should you use what?

Use FTP when:

You are working with legacy systems
Security is handled elsewhere
Devices only support FTP
You need maximum compatibility

Use FTPS when:

Existing FTP workflows already exist
You need encryption
You want minimal migration effort
Enterprise systems already support FTPS

Use SFTP when:

Building new integrations
Operating in cloud infrastructure
Simplicity and security matter
Firewall friendliness matters
You want a cleaner operational model

Cloud FTP vs Cloud SFTP

This distinction also explains why we recently launched both dedicated Cloud FTP and Cloud SFTP content clusters.

Even though the business problem is similar, the operational realities are often very different.

FTP/FTPS workflows are extremely common in:

Legacy enterprise integrations
Banking
Manufacturing
Surveillance systems
Embedded and industrial devices

SFTP workflows are much more common in:

Modern DevOps environments
Cloud infrastructure
Linux-based automation
CI/CD pipelines
Security-sensitive workflows

In reality, most companies end up supporting both.

The future of file transfer infrastructure

One interesting observation is that despite APIs, event streaming and cloud-native systems, file transfers simply refuse to die.

And honestly:

That makes sense.

Files are still one of the simplest and most reliable interoperability formats between systems.

The future is probably not "FTP vs APIs".

The future is likely:

File transfers
APIs
Webhooks
Event-driven automation

...working together.

Which is also why modern file infrastructure increasingly focuses less on the transfer protocol itself, and more on the surrounding ecosystem:

Automation
Security
Auditability
Scalability
Operational simplicity

If you're interested in that direction, we explored this further here:

→ /tutorials/ftp-integrations-api-webhooks/

Final thoughts

FTP, FTPS and SFTP all solve the same core problem:

Moving files between systems.

But technically and operationally, they are very different tools designed in very different eras of computing.

Understanding those differences helps explain:

Why FTP still exists
Why FTPS remains common
Why SFTP dominates modern infrastructure

And perhaps most importantly:

Why file transfers remain a critical part of infrastructure in 2026.