FTP vs FTPS vs SFTP: The Differences That Actually Matter

If you searched "FTP vs SFTP" or "SFTP vs FTPS" and want the answer in one paragraph: FTP is the original 1971 file-transfer protocol — cleartext, dual-port, no encryption. FTPS (also called FTP-SSL, full form: FTP over SSL/TLS) is the same FTP protocol wrapped in a TLS handshake — encrypted, but keeps every FTP quirk including the dual-port firewall pain. SFTP (full form: SSH File Transfer Protocol) is not actually FTP at all — it's a file-transfer subsystem of SSH that runs over a single port with native encryption and key-based authentication. For a new deployment in 2026, the answer is almost always SFTP.

The three protocols at a glance

Feature	FTP	FTPS	SFTP
Underlying protocol	FTP (RFC 959)	FTP + TLS	SSH (RFC 4253)
Ports	21 + 20 / ephemeral	21 + ephemeral (explicit), 990 + 989 (implicit)	22
Encryption	None — cleartext	TLS (negotiated)	Native to SSH
Auth	Username + password	Username + password + server cert	Username + password OR SSH key
Firewall complexity	High (dual-channel, passive ranges)	High (same as FTP)	Low (single port)
Year specified	1971 (first), 1985 (RFC 959)	~1996 (RFC 2228)	~2001 (SSH-2 draft)
Modern recommendation	Avoid — legacy only	Acceptable if you must use FTP semantics	Default for new deployments

The three names share four letters in a different order, but on the wire they're not interchangeable. An FTP client cannot connect to an SFTP server. An SFTP client cannot connect to an FTPS server. Compatibility starts and ends at the protocol name.

What FTP actually is

FTP was specified in RFC 114 (1971) and reached its enduring form in RFC 959 (1985). It's the original file-transfer protocol of the internet — predating HTTP by almost two decades. Two design choices from that era still drive every FTP problem you'll have today:

• Dual-channel. FTP separates the control connection (login, directory listing, transfer commands) on port 21 from the data connection (the actual file bytes) on port 20 or an ephemeral high port. The dual-channel design made sense in 1971 when networks had no firewalls and every host had a public IP; today it's the reason FTP is painful through every firewall and NAT.
• Cleartext. FTP was specified before TLS existed. Usernames, passwords, commands, and file contents all travel over the network as plain text. Anyone on the network path between client and server can read everything. For anything sensitive — which today means almost everything — plain FTP is a non-starter.

FTP is still in active use, mostly because it has 50+ years of installed-base inertia. IoT devices, scientific instruments, old retail POS systems, scanned-document workflows in healthcare and finance — all places where the equipment ships with an FTP client and the cost of upgrading is more than the cost of running the old protocol behind enough firewalls to make it tolerable. New deployments should not start here.

What FTPS actually is

FTPS — short for FTP-SSL or FTP over SSL/TLS — is plain FTP with a TLS wrapper added in the late 1990s. It was specified in RFC 2228 (1997) and formalized in RFC 4217 (2005). The protocol semantics are identical to FTP: same commands, same dual-channel structure, same passive vs active mode — but the connections are encrypted with TLS, and the server presents an X.509 certificate the client validates.

Two flavors exist, and they connect to different ports:

• Implicit FTPS — TLS handshake happens immediately, before any FTP commands. Control on port 990, data on port 989. Specified by Microsoft in the late 1990s, considered deprecated in modern deployments but still seen on legacy systems.
• Explicit FTPS — Client connects to plain port 21, then issues AUTH TLS to upgrade the connection to TLS. The data channel also gets its own TLS handshake. This is the modern FTPS standard.

FTPS solves FTP's encryption problem but inherits every other FTP quirk:

• Dual-channel. Still two connections, still active vs passive mode, still passive-port-range firewall headaches.
• Certificate management. You now have a TLS certificate to install, renew, and rotate. Cert mismatch or expiration breaks the connection entirely.
• Deep packet inspection unfriendly. Some firewalls drop FTPS data connections because they can't see inside the encrypted stream to track the control-channel PORT / PASV negotiation.

FTPS makes sense when you have an existing FTP integration that needs to stay FTP-shaped (an automated partner workflow, a script that uses FTP commands, a vendor that only supports FTP) and you need to add encryption. For anything greenfield, SFTP is the cleaner answer.

What SFTP actually is

SFTP — full form SSH File Transfer Protocol — is the most confusingly named protocol in this trio. It is not FTP. It shares no code, no commands, no design lineage. SFTP is a file-transfer subsystem of SSH that runs entirely inside a regular SSH session over port 22.

The mechanics:

1. Client opens an SSH connection to the server on port 22 (or whatever non-standard port the SSH daemon is on).
2. Client authenticates — either with a password or, more commonly in production, with an SSH key pair.
3. Client requests the sftp subsystem; the server spawns an SFTP server inside the existing SSH session.
4. File operations — ls, get, put, mkdir, permission changes, symlinks — all flow over the single encrypted SSH channel.

Everything SFTP gets, it gets from SSH: encryption by default, key-based authentication, single-port operation, host-key verification, modern cipher suites. SSH is how nearly every server on the internet is administered, so SFTP inherits 20+ years of hardening, library support, and operational tooling.

For most teams choosing a file-transfer protocol in 2026, SFTP is the right answer:

• One outbound port (22). Firewall config is trivial.
• Encrypted by default; no TLS certificate to manage.
• Native SSH key auth means you can rotate credentials without touching passwords.
• Supported by every modern file-transfer client, every cloud platform, and every Unix/Linux server out of the box.

Why the names are so confusing

The taxonomy is messy because the three protocols arrived at different times and named themselves with the FTP family branding for marketing reasons, not technical accuracy:

• FTP was named in 1971 when there were no other file-transfer protocols on the internet to confuse it with.
• FTPS was branded "FTP over SSL/TLS" in the late 1990s because that's literally what it is. The "S" suffix mirrors HTTP → HTTPS.
• SFTP got the name when the SSH-2 protocol's authors needed to call its file-transfer subsystem something. "SSH File Transfer Protocol" is technically descriptive, but the four-letter acronym SFTP looks parallel to FTP/FTPS and creates the illusion that all three are members of the same protocol family. They aren't.

The single most common buyer confusion: assuming an "FTP client" can speak SFTP, or that an "SFTP server" is just FTP with encryption turned on. Neither is true. They're different protocols that solve the same job differently.

Which protocol to pick for a new deployment in 2026

If you're standing up a new file-transfer endpoint and have a free hand, the order is:

1. SFTP — the default. Almost every modern use case lands here. One port, key auth, ubiquitous client support.
2. FTPS (explicit) — only if a specific partner or vendor cannot speak SFTP and you need FTP semantics with encryption. Treat this as a compatibility-driven choice, not a default.
3. Plain FTP — only for legacy device interop where there is no other path (some IoT cameras, some old POS systems, some scientific instruments). Isolate the FTP endpoint, treat the credentials as untrusted, and never accept anything sensitive over it.

The 5% of cases where this hierarchy doesn't apply: a regulated workflow that contractually requires FTPS specifically, a multi-decade legacy integration where SFTP would mean rewriting partner code, or a niche industry standard that mandates FTP-shaped automation. In those cases the protocol picks you.

Why all three are increasingly painful to self-host

Running an FTP, FTPS, or SFTP server yourself in 2026 is more operational overhead than most teams want to absorb. The protocol layer is only the visible part of the work. The full picture is more like:

• Protocol patching. OpenSSH advisories, vsftpd advisories, FileZilla Server vulnerabilities — every protocol has a CVE cadence, and each one is a maintenance window.
• TLS certificate management. For FTPS especially. Let's Encrypt automation breaks in interesting ways with FTP's dual-channel design.
• User and key management. Adding a user, rotating a key, revoking access for a departing partner — each one is a shell script you wrote three years ago and haven't touched since.
• Audit logging. Every regulated industry asks "show me who downloaded that file and when." Stitching audit logs out of vsftpd.log is possible; making it survive a SOC 2 audit is something else.
• Firewall rules and passive port ranges. Half the FTP support tickets in the world are some variant of "I can list the directory but the file transfer hangs." The fix is always passive-port-range firewall rules.
• Compliance posture. SOC 2, HIPAA, GDPR, PCI — each one is a question of whether your FTP server's configuration matches the controls your auditor wants documented. Doing this for a self-hosted server means owning the entire scope yourself.

For teams that want the protocols without owning the operational surface, the answer is a hosted managed-file-transfer platform.

The modern way: stop running file-transfer servers yourself

Files.com is the File Orchestration Platform we'd recommend for any team running FTP, FTPS, or SFTP workflows in 2026. The platform exposes all three protocols on their standard ports, on a subdomain Files.com provisions for you, and handles the operational surface that makes self-hosting painful:

• SFTP (port 22), FTP (21), FTPS (21 + 990), and WebDAV — all on one endpoint. Your trading partners connect with whatever client they already use.
• Native SSH key authentication. Per-user keys, rotation, revocation. No shell-script administration.
• Automatic TLS certificates. Provisioned and renewed via Let's Encrypt; modern cipher suites by default. No FTPS cipher debugging.
• Passive mode auto-configured. No port ranges to open on your firewall. Files.com handles its end of the data-channel choreography.
• Audit logging on every operation. Per-file, per-user, immutable. Drops straight into a SOC 2 evidence trail.
• SOC 2 Type II and HIPAA-BAA out of the box. The compliance work is on Files.com's side of the line, not yours.
• Modern features the protocols never gave you. REST API, SDKs in 8 languages, AS2 partner messaging, automation workflows, MFA, shareable links with passwords and expiry, a browser-based file manager that exposes the same files as the protocols.

Start a free Files.com trial — no credit card, provisioned in about 10 minutes. Point your existing FTP / FTPS / SFTP clients at the subdomain and the rest is the platform.

For the narrow set of teams that must run file-transfer infrastructure inside their own datacenter — air-gapped environments, strict data-residency mandates, regulated workloads that prohibit multi-tenant cloud — the free ExaVault on-premise appliance handles SFTP / FTP / FTPS / WebDAV from a self-hosted VM image.

FAQ

Is SFTP just FTP with encryption?

No. SFTP is a different protocol entirely — a file-transfer subsystem of SSH. It shares no code or design lineage with FTP. The name parallels FTP for branding reasons, not technical ones. An FTP client cannot connect to an SFTP server.

What does FTPS stand for?

FTPS is FTP over SSL/TLS (sometimes written FTP-SSL). It's the original FTP protocol with a TLS encryption layer added — same commands and semantics, just encrypted.

Is SFTP faster than FTPS?

In practice they're close enough that throughput is rarely the deciding factor. FTPS can have lower CPU overhead on a single large transfer because TLS adds less per-packet overhead than SSH; SFTP can be faster on many small files because there's only one connection to set up. For real workloads, network latency and disk I/O dominate either way.

Which is more secure, SFTP or FTPS?

Both are secure when configured correctly. SFTP is harder to misconfigure: encryption is mandatory, key-based auth is native, and a single port reduces the attack surface. FTPS requires explicit TLS configuration, valid certificates, and careful handling of the dual-channel design — more places for a misconfiguration to leave traffic exposed.

Can I use FTP over SSH?

No — that's a common confusion. SSH doesn't tunnel FTP; it provides its own file-transfer subsystem called SFTP. If you want file transfer over an SSH connection, use SFTP. If you want FTP commands specifically, you need FTPS (with TLS) or plain FTP (without).

Why is FTP still around if it's insecure?

Installed-base inertia. Decades of equipment, vendor integrations, scripts, and partner workflows already speak FTP. The cost of upgrading the long tail of FTP-only devices is higher than the cost of running the protocol behind enough network controls to manage the risk. Most teams running FTP today are doing so as a compatibility bridge, not as a new design choice.

What's the difference between SFTP and SCP?

Both move files over SSH, but they have different shapes. SCP is a one-shot copy command — push or pull a file, no other operations. SFTP is interactive: list directories, change permissions, rename files, resume interrupted transfers. For anything beyond a single file copy, SFTP is the better choice. SCP has also fallen out of favor in modern OpenSSH releases due to legacy protocol issues; SFTP is the replacement OpenSSH itself recommends.

Can the same server handle FTP, FTPS, and SFTP?

Yes. Most managed-file-transfer platforms (including Files.com) expose all three protocols on the same backend storage, so the same files are accessible regardless of which protocol the client speaks. Self-hosting all three from a single open-source server is also possible but harder — you typically run vsftpd or ProFTPD for FTP/FTPS and OpenSSH for SFTP, with shared user accounts and a shared filesystem.