SFTP vs FTP: Why You Should Stop Using Plain FTP

Many people still upload website files with plain FTP because it is what their old tutorial, theme vendor or agency used. FTP dates from the early 1970s and 1980s, and it was designed for a network where nobody expected attackers. It sends everything, including your username and password, in plain text. Anyone who can observe the connection, on the same Wi-Fi or at an intermediate network point, can read your credentials and then take over your site.

The three options

Protocol	What it is	Encrypted?	Typical port
FTP	The original File Transfer Protocol	No	21 (plus other ports for data)
FTPS	FTP wrapped in TLS, the same technology as HTTPS	Yes, if configured properly	21 (explicit) or 990 (implicit)
SFTP	A file transfer protocol that runs inside an SSH connection	Yes	22

The names are confusing. SFTP is not "FTP with security added". It is a different protocol that happens to do similar jobs, built on SSH. FTPS is the one that is actually FTP plus TLS.

Why plain FTP is a problem

• Credentials in clear text: your login can be captured on any untrusted network.
• Files can be read or changed in transit: including configuration files containing database passwords.
• Firewall difficulties: FTP uses separate connections for commands and data, with active and passive modes, which complicates firewalls and NAT.
• Brute-force exposure: an open FTP service is a constant target for password guessing.

Why SFTP is usually the best choice

• Everything is encrypted, commands, credentials and data.
• One port makes firewalling simple.
• Key-based authentication is supported, so you can log in without a password at all.
• Server identity verification: your client remembers the server's host key and warns you if it changes, which helps detect interception.
• Wide client support: FileZilla, Cyberduck, WinSCP, Transmit and the command line all support it.

FTPS is a perfectly acceptable second choice when a server only offers it, provided you use explicit TLS and validate the certificate. The goal is simply to stop sending credentials in plain text.

Using key-based authentication

With SSH keys you generate a key pair: a private key that stays on your computer and a public key that you install on the server. When you connect, your client proves it holds the private key without sending it. Keys are far harder to guess than passwords and cannot be captured by phishing.

1. Generate a key pair on your computer, for example with ssh-keygen -t ed25519.
2. Protect the private key with a passphrase.
3. Add the public key to the server account's authorised keys, through your hosting panel or the command line, where your plan allows it.
4. Configure your SFTP client to use the private key.
5. Where you control the server, disable password login for SSH once keys work.

Best practices for any file transfer

• Create separate accounts for each person or tool, with access only to the folders they need.
• Remove accounts when contractors finish.
• Use strong, unique passwords stored in a password manager, and avoid saving them in shared client configuration files.
• Do not store site passwords in your client on a shared or unmanaged computer.
• Watch for client warnings about changed host keys or certificate problems. They are an alert, not an annoyance.
• Prefer deployment from version control over manual uploading, so code changes are tracked and reversible.
• Delete leftover files such as backups, old archives and test scripts after uploading.
• Avoid uploading with 777 permissions or running transfers as an administrator account.

How to move away from FTP

1. Check what your hosting plan offers. Look in the control panel for FTP and SSH access settings.
2. Switch your client's protocol to SFTP, set port 22 and test with a harmless file.
3. Update scripts, plugins and CI jobs that use FTP, such as automatic deployment and backup tools.
4. Disable plain FTP accounts you no longer use.
5. Check that no software, such as WordPress updates through FTP credentials in the config, still stores FTP passwords in plain text files.

WordPress and file transfers

WordPress can ask for FTP details to install plugins when it cannot write files directly. Needing this usually means a file ownership problem. Fix the ownership instead of storing FTP credentials in the site, and if you must use a transfer method from inside WordPress, choose SSH/SFTP or FTPS over plain FTP.

Understanding the host key warning

The first time your client connects to an SFTP server it displays the server's fingerprint and asks whether you trust it. Verify it against the fingerprint your host publishes, if available, then accept. The client stores it. If you later see a warning that the host key has changed, stop. It can happen legitimately when a server is rebuilt, but it can also mean someone is intercepting the connection. Ask your host before accepting a changed key.

What about web-based file managers?

Control panel file managers run over HTTPS, so they are encrypted in transit, and they are handy for small edits and permission changes. They are not a good fit for large uploads or full deployments, where SFTP or a version-control based workflow is faster and leaves a better record of what changed. Use whichever suits the task, as long as the connection is encrypted and the account is protected by a strong password and 2FA where the panel supports it.

Secure access on your plan

Zebra Hosting Cloud runs Plesk on every plan, where you manage file access and accounts from the panel. For full command-line and SSH control, a VPS gives you the flexibility to run your own access policies; see the VPS plans.