FTP vs SFTP vs FTPS, Explained Properly

Three acronyms, four letters each, one letter apart. You would reasonably assume they are variations on a theme. Two of them are. The third is a completely unrelated protocol that happens to have been given a colliding name, and that single fact explains most of the confusion people have when configuring a server.

The short answer: SFTP and FTPS both encrypt everything, but they are different protocols. SFTP (SSH File Transfer Protocol) runs inside SSH, uses a single connection on port 22 and accepts SSH keys. FTPS (FTP Secure, also called FTP over SSL or FTP over TLS) is classic FTP with TLS added, uses two connections on port 21 (explicit) or 990 (implicit) and authenticates the server with a certificate. Plain FTP encrypts nothing. If the server offers SSH, use SFTP; if it only offers FTP, use FTPS; use plain FTP only on a network you trust.

Here is the full comparison, and then the detail.

FTP: the original

FTP moves files using two separate TCP connections — one for commands, one for the bytes — and sends everything, credentials included, as plain text. How FTP works covers the mechanics; what matters here is that it offers no encryption and no way to verify you are talking to the right server.

Use it only on a network you already trust, and only when the other end offers nothing better.

FTPS: FTP with TLS wrapped around it

FTPS is genuinely FTP. Same commands, same two connections, same quirks — with a TLS layer added, exactly the same technology that turns HTTP into HTTPS. It comes in two flavours:

Explicit FTPS (AUTH TLS) connects normally to port 21 in the clear, then issues an AUTH TLS command to upgrade the connection to encrypted before authenticating. This is the modern, recommended form, and it is what almost everyone means by “FTPS” today.

Implicit FTPS assumes TLS from the very first byte and traditionally listens on port 990. It was deprecated, then quietly kept alive by hardware and legacy servers that never moved. Upstream supports both because in practice you still meet both.

Because it is still FTP underneath, FTPS keeps FTP’s two-connection design — and makes the firewall situation worse. A firewall that inspects the control connection to learn which data port to expect can no longer read it, because it is now encrypted. Hence the classic FTPS failure: you authenticate perfectly, then the directory listing times out.

FTPS also introduces server identity: the server presents a TLS certificate. If it is signed by a public authority it validates like any HTTPS site. Very often on a self-hosted box it is self-signed, which is where certificate fingerprints and trust-on-first-use come in.

FTPS, FTPES, “FTP over SSL”: one protocol, many names

Much of the confusion around FTPS is naming. All of these mean FTP with TLS encryption:

• FTPS — the umbrella term (“FTP Secure”), defined in RFC 4217.
• FTPES or FTP over explicit TLS — explicit FTPS on port 21. Clients like FileZilla use this name.
• FTP over SSL / FTP-SSL / secure FTP — older names from when the encryption layer was still SSL. Modern servers use TLS; the old name stuck.
• Implicit FTPS — the port-990 variant.

FTPES is usually preferred over implicit FTPS because it is the standardised form, uses the normal port 21, and lets one server accept both encrypted and (if the admin allows) plain connections on the same port. Implicit FTPS was never part of the RFC and survives mainly on older servers and devices.

SFTP: not FTP at all

SFTP is the SSH File Transfer Protocol. It is not FTP with an S bolted on. It shares no commands, no code, no port and no design lineage with FTP. It was created as part of SSH in the late 1990s and it works completely differently:

• One connection. Everything — commands, listings, file data — is multiplexed inside a single encrypted SSH channel on port 22. There is no data connection to be blocked, so there is no active/passive mode and no firewall drama.
• Structured operations. Listing a directory returns typed records, not a human-formatted line that has to be parsed. Filenames, sizes, timestamps and permissions arrive unambiguously — none of the hidden-file weirdness of FTP listings.
• SSH authentication. Passwords work, but so do SSH keys, which are dramatically stronger and cannot be phished or brute-forced — see using one from a graphical client.
• Free with SSH. If a server accepts SSH logins, it almost certainly accepts SFTP already, with no additional service to install or configure.

The practical upshot: on any Linux box you rent, SFTP is available right now, works through any firewall that permits SSH, and is strictly better than the alternatives.

SFTP vs FTPS, head to head

If you have already ruled out plain FTP, this is the decision that remains:

Security is a draw on paper: both use current, strong encryption when configured properly. In practice SFTP wins on two points. Key-based logins remove passwords from the equation, and a single port leaves less to misconfigure. FTPS can be just as secure, as long as the client actually checks the certificate and doesn’t click through the warning.

Firewalls are where the two really differ. SFTP needs one port. FTPS needs the control port plus a data connection for every listing and every file, and because the control channel is encrypted, firewalls and NAT routers can no longer read it to open that data port automatically. Most “FTPS connects but the folder never loads” problems come from this. Active vs passive FTP explains the mechanics.

Availability settles most real cases. You rarely choose: you use what the server offers. Any Linux server with SSH already speaks SFTP. A shared hosting plan without shell access usually offers FTPS only.

What about SCP?

SCP is the older SSH-based copy command. It transfers a file and stops — no directory browsing, no resume, no rename. It has also been deprecated in OpenSSH in favour of SFTP, partly for security reasons in how it handled filenames. If you are choosing today, choose SFTP.

So which should you use?

Use SFTP whenever the server offers SSH. It is encrypted, it authenticates the server, it supports keys, it passes through firewalls, and it has none of FTP’s protocol quirks. This covers nearly every VPS, cloud instance and managed Linux server.

Use FTPS when your host offers FTP over TLS but no shell access. This is common on cheap shared hosting and on NAS devices. Prefer explicit mode on port 21; fall back to implicit on 990 only if the server insists.

Use FTP only on a trusted local network, talking to a device that supports nothing else — an old NAS, a camera, a piece of lab equipment. Never across the internet.

If your host offers only plain FTP for a public-facing website, that is a reasonable signal to consider a different host.

Step by step

1. Check for SSH access first — if your hosting panel mentions SSH, shell access or a terminal, you have SFTP. Use it and stop here.
2. Otherwise look for FTPS — in your host’s documentation, “FTP over TLS”, “explicit TLS” or “secure FTP” all mean FTPS on port 21.
3. Set the protocol explicitly in your client — do not rely on autodetection. In Upstream, the site editor has a protocol selector (FTP, FTPS, SFTP, S3) and, for FTPS, a choice between explicit (port 21) and implicit (port 990).
4. Verify the server’s identity on the first connection — you will be shown a certificate or host-key fingerprint. Compare it with what your host published, then trust it once.
5. If FTPS listings hang, switch to passive mode — and if that still fails, the firewall is the problem, not your credentials.

Questions people ask

Is SFTP just FTP with encryption?

No. They are unrelated protocols with unfortunately similar names. SFTP runs inside SSH on port 22 and shares nothing with FTP beyond the general idea of moving files.

Which is more secure, SFTP or FTPS?

Both encrypt properly, so neither is meaningfully weaker in transit. SFTP is usually the better choice in practice because it supports key-based authentication, needs only one port, and has a simpler attack surface. FTPS with a properly validated certificate is perfectly secure too.

Which is faster?

They are close enough that it rarely matters. FTPS can edge ahead on very large single files because its data connection is a plain TLS stream with less framing overhead than SSH channels. In real use, how many files your client transfers concurrently matters far more than the protocol.

Can I use SFTP on port 21?

Only if the server was deliberately configured that way, which is unusual. SFTP normally follows SSH on port 22. If a host tells you “SFTP on port 21”, double-check they do not actually mean FTPS.

What is the difference between SFTP and FTPS?

SFTP is a subsystem of SSH: one encrypted connection on port 22, with password or SSH-key login. FTPS is the old FTP protocol wrapped in TLS: two connections, port 21 or 990, and the server proves its identity with a certificate. They encrypt equally well, but they are not compatible — a client must speak the one the server offers.

Is FTP over SSL the same as SFTP?

No. “FTP over SSL” is FTPS — FTP with an SSL/TLS layer. SFTP is a separate protocol that runs over SSH. A server that offers one doesn’t automatically offer the other.

What does FTPS stand for?

FTPS stands for FTP Secure, sometimes written FTP-SSL. It is FTP with TLS (formerly SSL) encryption added, the same way HTTPS is HTTP with TLS.

Why is FTPES preferred over implicit FTPS?

FTPES (explicit FTPS) is the version defined by the standard, RFC 4217. It uses the regular FTP port 21 and upgrades to TLS with the AUTH TLS command. Implicit FTPS on port 990 was never standardised and is kept around mainly for older servers.

Does my Mac support all three?

Partly. macOS ships an sftp command in the Terminal, and curl can move single files over FTP and FTPS. The Finder can only mount FTP servers read-only, and has no SFTP or FTPS support at all. For browsing, uploading and managing files over all three protocols you need a dedicated client — see how to connect to an FTP server on a Mac.