FTP, FTPS, and SFTP all transfer files between computers. Beyond that, they share very little. They use different ports, different security models, different authentication methods, and in the case of SFTP, an entirely different underlying protocol. Choosing the wrong one for your situation means either exposing credentials and file contents in plaintext or dealing with unnecessary firewall complexity.
The short answer: use SFTP. But understanding why requires knowing how each protocol actually works.
FTP: the original, and why you should not use it
FTP (File Transfer Protocol) was designed in 1971. The internet at the time was a small research network where security was not a concern. FTP reflects that era – it transmits everything in plaintext, including your username and password.
How FTP works
FTP uses two separate TCP connections:
Control connection (port 21): Sends commands and receives responses. This connection stays open for the duration of the session.
Data connection: Transfers actual file contents. A new data connection is opened for each file transfer or directory listing. The port used depends on whether FTP is running in active or passive mode.
In active mode, the server initiates the data connection back to the client on a port the client specifies. This fails in most modern network environments because firewalls typically block inbound connections to client machines.
In passive mode, the server opens a random high-numbered port and tells the client to connect to it. This works better with firewalls but requires the firewall to allow outbound connections to arbitrary high ports on the server.
Why FTP is not acceptable for web hosting
No encryption. Every byte transmitted over FTP – including your password, every file you upload, every directory listing – is plaintext. Anyone with access to the network path between you and the server can read it. This includes:
- Your ISP
- The operators of any Wi-Fi network you are on
- Anyone performing a man-in-the-middle attack on your connection
Credentials exposed on every login. Your hosting username and password travel in plaintext each time you connect. A single intercepted FTP session gives an attacker full access to your account.
Firewall problems. The two-connection model and dynamic port negotiation cause constant problems with NAT, firewalls, and corporate network policies. FTP connections that work on one network fail silently on another.
No integrity verification. FTP provides no mechanism to verify that a transferred file arrived intact and unmodified. A man-in-the-middle could inject malicious code into files you upload without your knowledge.
FTP has no legitimate place on a modern web server. If your hosting provider only offers FTP (no SFTP, no FTPS), that is a significant red flag about their security posture.
FTPS: FTP with encryption added
FTPS (FTP Secure, sometimes called FTP-SSL) adds TLS encryption to FTP. It was standardized in 1999 as a way to address FTP’s plaintext problem without replacing the entire protocol.
How FTPS works
FTPS comes in two variants:
Explicit FTPS (AUTH TLS): The client connects to port 21 (standard FTP control port) and sends an
AUTH TLS
command to upgrade the connection to TLS. The control connection is then encrypted. The data connection is also encrypted when the client sends
PROT P
.
Implicit FTPS: The connection starts as TLS immediately, on port 990. There is no plaintext phase. The server expects TLS from the first byte.
Explicit FTPS is the more common variant today. Implicit FTPS is considered deprecated by the relevant RFC but still widely supported.
What FTPS fixes
FTPS encrypts the control and data connections, solving FTP’s biggest problem. Your credentials and file contents are protected in transit.
What FTPS does not fix
FTPS inherits FTP’s architecture. It still uses two separate connections, still has the active/passive mode complexity, and still requires firewalls to allow dynamic port ranges for data connections. The encryption layer sits on top of a protocol that was not designed with modern network environments in mind.
FTPS also requires a valid SSL/TLS certificate on the server side. The client must either trust the server’s certificate (validating it against a trusted CA) or accept it explicitly. Certificate management adds operational overhead.
In passive mode with FTPS, the data connections are encrypted, but the server still opens random high-numbered ports for each transfer. Firewalls need to allow outbound traffic to these ports, which requires either a broad rule or FTPS-aware firewall inspection.
When FTPS makes sense
FTPS is appropriate when:
- You need to interoperate with a legacy system that supports FTPS but not SFTP
- Your organization has specific compliance requirements that mandate FTPS (some older PCI DSS implementations specified FTPS)
- You are working with a partner or client whose systems only support FTPS
In most hosting scenarios, FTPS is the second-best option after SFTP. It is secure enough but more complex to configure and troubleshoot.
SFTP: the right choice for web hosting
SFTP (SSH File Transfer Protocol) is not FTP with SSH added. It is a completely different protocol, developed independently, that happens to run as a subsystem of SSH.
How SFTP works
SFTP uses a single TCP connection on port 22 – the SSH port. Everything flows through this one connection: authentication, commands, and file data. The SSH layer encrypts the entire session from the first byte.
There is no control/data split. No active/passive mode. No dynamic port negotiation. One port, one connection, everything encrypted.
Security model
SFTP inherits SSH’s security model, which is mature, well-audited, and widely deployed. The SSH protocol handles:
Key exchange: Client and server negotiate a shared secret using algorithms like Diffie-Hellman or ECDH. Neither side transmits the secret key – it is derived mathematically.
Server authentication: The server presents its host key. The client verifies this against previously accepted keys (stored in
~/.ssh/known_hosts
). This prevents man-in-the-middle attacks by ensuring you are talking to the same server you connected to before.
Encryption: The session is encrypted using symmetric encryption (typically AES) with keys derived from the key exchange.
User authentication: SFTP supports both password authentication and SSH key authentication. SSH key authentication eliminates the password entirely – you authenticate with a cryptographic key pair that cannot be brute-forced or phished. See SSH keys for setup instructions.
Firewall simplicity
Port 22, TCP. One rule: allow outbound TCP to port 22. That is the entire firewall configuration for SFTP. No passive mode, no high port ranges, no FTPS-aware inspection required.
No certificate management
SFTP uses SSH host keys, not SSL certificates. Host keys do not expire. You do not need to purchase or renew them. The OpenSSH server generates them automatically on installation. This is a significant operational simplification compared to FTPS.
Built into OpenSSH
Virtually every Linux server runs OpenSSH. SFTP is a subsystem of OpenSSH that is enabled by default. There is nothing to install or configure separately. If SSH is enabled on your server, SFTP works immediately.
Direct comparison
| FTP | FTPS | SFTP | |
|---|---|---|---|
| Encryption | None | TLS | SSH |
| Default port | 21 | 21 (explicit) / 990 (implicit) | 22 |
| Connections | Two (control + data) | Two (control + data) | One |
| Firewall complexity | High | High | Low |
| Certificate required | No | Yes | No |
| Authentication | Password only | Password only | Password or SSH key |
| Based on | FTP (1971) | FTP + TLS | SSH subsystem |
| Built into OpenSSH | No | No | Yes |
| Recommended | No | Only for legacy compatibility | Yes |
Choosing between them
Use SFTP for virtually everything. New hosting setups, WordPress file management, deployment pipelines, backups. If your server has SSH, SFTP is available and it is the best option.
Use FTPS only when required by a legacy system or compliance requirement that specifically mandates it and does not accept SFTP as an alternative. This scenario is rare and becoming rarer.
Never use plain FTP for anything that involves real credentials or real data. The only legitimate use of FTP today is in isolated lab environments where no sensitive data is involved and the network is trusted end to end.
FTP, FTPS, and SFTP in hosting control panels
On Hostney there are two distinct types of file transfer access:
SSH/SFTP access is the primary access method. Every hosting account includes SSH access, and SFTP comes with it automatically on the same SSH port. This is the recommended method for all file transfers – single connection, full encryption, SSH key support.
FTP users created through the control panel under FTP Users use FTPS – FTP with TLS encryption. These are separate accounts with their own credentials, independent of your SSH login. Use FTP user accounts when you need to give a third party (a developer, a designer) scoped file access without giving them SSH access to your account.
Plain unencrypted FTP is not available. All FTP user connections are encrypted via FTPS.
When configuring your client for an FTP user account, set the protocol to FTPS (not plain FTP). For your main account file transfers, use SFTP with your SSH credentials.
Configuring common SFTP clients
FileZilla
- Open Site Manager (File > Site Manager)
- Click New Site
- Set Protocol to SFTP – SSH File Transfer Protocol
- Enter host, port (22 or your custom SSH port), username
- Set Logon Type to Normal (password) or Key file (SSH key)
WinSCP
- New Session
- Set File protocol to SFTP
- Enter host name, port, username, password
- For SSH key: Advanced > SSH > Authentication > Private key file
Cyberduck
- Open Connection
- Select SFTP (SSH File Transfer Protocol) from the dropdown
- Enter server, username, password or SSH key
Command line
bash
sftp username@hostname
For a custom port:
bash
sftp -P 2222 username@hostname
For SSH key authentication:
bash
sftp -i ~/.ssh/id_ed25519 username@hostname
For the full reference of SFTP commands once connected, see SFTP Commands: A Complete Reference Guide.
SSL certificates and SFTP
A common point of confusion: SFTP does not use SSL certificates. It uses SSH host keys. If you install or renew an SSL certificate on your server, it has no effect on SFTP connections.
SSL certificates are used by HTTPS (web traffic), FTPS, SMTPS, and IMAPS. SFTP uses SSH host keys exclusively.
If you are working with SSL certificates for your website’s HTTPS configuration, that is a separate concern from SFTP file transfers. See How to install an SSL certificate for the web server SSL configuration process.
Summary
FTP is plaintext and outdated – do not use it. FTPS adds TLS encryption to FTP but keeps FTP’s complex two-connection architecture. SFTP is a completely different protocol running over SSH – single connection on port 22, full encryption, no certificates required, built into every Linux server. For web hosting file transfers, SFTP is the correct choice in almost every situation. Use FTPS only when required by a system that does not support SFTP. Never use plain FTP for anything involving real credentials or data.