FTP vs FTPS vs SFTP: Choosing a Protocol and Using a Browser File Manager

File transfer protocols are old enough to have accumulated real differences that matter during an incident. Choosing FTP, FTPS or SFTP is a security decision first and a compatibility decision second — and the wrong choice leaks credentials, not just files.

The three protocols, precisely

• FTP (port 21): unencrypted. Usernames, passwords and file contents cross the network in clear text. It also uses a second, dynamically negotiated data connection (active or passive mode), which complicates firewalls. There is no honest reason to use it in 2026 except talking to a device that supports nothing else.
• FTPS (FTP over TLS): FTP wrapped in TLS. Explicit FTPS starts on port 21 and upgrades with an AUTH TLS command; implicit FTPS uses port 990 with TLS from the first byte. Encryption solves the credential leak, but the dual-channel design — and the firewall puzzles it causes — remain.
• SFTP (port 22): not FTP at all. It is a file-transfer subsystem of SSH: one connection, one port, authentication via password or key, and strong encryption by default. When both ends support it, SFTP is the correct answer.

Quick connectivity sanity checks from any shell:

openssl s_client -connect ftp.example.com:990
ssh -p 22 user@example.com -s sftp

The first should complete a TLS handshake; if the server only offers explicit TLS, test port 21 with openssl s_client -starttls ftp.

When a browser file manager fits

A full desktop client is overkill for most real-world tasks: fixing a broken .htaccess, uploading one plugin archive, editing a config file on a client’s hosting where you have FTP credentials but no SSH. A browser-based manager gives you browse, upload, download, rename and inline edit over FTPS or SFTP from any machine — including the borrowed laptop with no client installed. Use it for targeted fixes; use a real client with queueing and sync for bulk transfers.

Credential handling

1. Prefer SFTP with a key if the host allows it; fall back to FTPS otherwise, and treat plain FTP as a last resort to be disabled after use.
2. Never store production FTP credentials in a spreadsheet, chat message or ticket body — hosting panels leak those to anyone with read access.
3. Create per-person or per-task accounts where the host supports it, and delete them when the task ends; a shared webmaster login outlives every person who knew it.
4. If credentials must be shared once, share them through a channel that expires, and change the password afterwards.
5. After finishing work through the browser manager, disconnect the session rather than leaving it idle — an open authenticated session on a shared or public machine is an access path long after you walked away.

The browser FTP file manager on WhoDNS speaks FTP, FTPS and SFTP, stores server entries with AES-256-GCM-encrypted secrets, and logs each connection — so the quick fix does not become the reason credentials end up in a chat log.