Ftp vs Rsync
FTP is a 1970s file-shoveling protocol that sends your credentials in plaintext and copies everything blindly. Rsync diffs, compresses, encrypts over SSH, and resumes. This isn't close.
The short answer
Rsync over Ftp for most cases. Rsync moves only the bytes that changed, runs over SSH by default, and resumes interrupted transfers.
- Pick Ftp if stuck talking to legacy gear, a vendor appliance, or a managed host that literally only speaks FTP and you have no SSH access. That's the only excuse left
- Pick Rsync if doing anything else — backups, deployments, mirroring directories, or moving large trees over the network. Default to rsync and don't look back
- Also consider: rsync over SSH is the baseline. If you need a browser-friendly web upload UI instead of a sync tool, that's SFTP or object storage, not FTP.
— Nice Pick, opinionated tool recommendations
The Verdict
Rsync. Decisively. FTP is a museum piece that survives only because cheap shared hosts and crusty appliances refuse to die. It opens two TCP connections, ships your username and password in plaintext, and copies every file in full whether or not a single byte changed. Rsync does the opposite of all three: one encrypted SSH channel, no credential leakage, and a delta algorithm that transfers only the differences. The first time you re-sync a 50GB directory and rsync finishes in eight seconds because nothing changed, you understand why FTP deserves the boot. The only scenario where FTP wins is the one where someone else already chose it for you — a managed host with no shell access. That's not a feature of FTP; it's a hostage situation. Everywhere you have a real choice, rsync is the answer, and the gap is not subtle.
Security
This is where FTP stops being merely outdated and becomes negligent. Plain FTP transmits credentials and file contents in cleartext — anyone on the path can read your password with a packet sniffer. FTPS bolts TLS on top but inherits FTP's nightmare of dynamic data ports that firewalls and NAT despise, so it's perpetually half-broken. Rsync, by contrast, rides over SSH: one port, fully encrypted, authenticated with keys you already trust. No passwords on the wire, no second data channel for a firewall to mangle, no surprises. You get host verification, key-based auth, and the same hardened transport you use for every other server task. If your threat model includes 'people exist,' FTP fails it. Rsync was built assuming the network is hostile, which in 2026 is simply correct. There's no security argument for FTP — only inertia dressed up as a requirement.
Performance and Efficiency
Rsync's delta-transfer algorithm is the whole point: it compares source and destination, then sends only the changed blocks, optionally compressed in flight with -z. Re-running a sync over a mostly-unchanged tree costs almost nothing. FTP has no concept of 'what changed' — it re-uploads entire files every time, so syncing a large directory where one log line moved means retransmitting gigabytes for fun. Rsync also resumes partial transfers (--partial) and preserves permissions, timestamps, symlinks, and ownership in one pass. FTP drops a connection mid-transfer and you start that file over from zero. For incremental backups, deploys, or mirroring, rsync turns hours into seconds. FTP's only 'speed' advantage is on a single fresh full transfer of one file with zero overhead — a contrived case you'll basically never hit. In the real world of repeated syncs, it isn't a contest.
When FTP Still Shows Up
FTP refuses to fully die for unglamorous reasons. Budget shared-hosting panels, ancient CMS workflows, embedded devices, scientific instruments, and some enterprise file-drop appliances still expose FTP and nothing else. If that's your reality, you don't have a choice to optimize — you have a constraint to tolerate. Even then, push for SFTP (SSH File Transfer Protocol, unrelated to FTPS) the moment shell access appears, because then rsync becomes available and the misery ends. Don't confuse 'my host only offers FTP' with 'FTP is fine.' It's not fine; it's imposed. And never reach for FTP to build something new in 2026 — choosing it voluntarily is choosing plaintext passwords and full retransfers as a lifestyle. Use rsync over SSH, or SFTP if you need a non-shell file channel. FTP is the protocol you escape, not the one you adopt.
Quick Comparison
| Factor | Ftp | Rsync |
|---|---|---|
| Security | Plaintext credentials; FTPS adds TLS but breaks firewalls | Runs over SSH — encrypted, key-based, single port |
| Transfer efficiency | Re-sends entire files every time | Delta algorithm sends only changed blocks, with compression |
| Resume / reliability | Dropped transfers restart the file from zero | --partial resumes interrupted transfers |
| Firewall/NAT friendliness | Dual-channel dynamic data ports are a NAT nightmare | One SSH connection, one port |
| Legacy/host availability | Ubiquitous on cheap hosts and old appliances | Needs SSH/shell access, not always offered |
The Verdict
Use Ftp if: You're stuck talking to legacy gear, a vendor appliance, or a managed host that literally only speaks FTP and you have no SSH access. That's the only excuse left.
Use Rsync if: You're doing anything else — backups, deployments, mirroring directories, or moving large trees over the network. Default to rsync and don't look back.
Consider: rsync over SSH is the baseline. If you need a browser-friendly web upload UI instead of a sync tool, that's SFTP or object storage, not FTP.
Ftp vs Rsync: FAQ
Is Ftp or Rsync better?
Rsync is the Nice Pick. Rsync moves only the bytes that changed, runs over SSH by default, and resumes interrupted transfers. FTP retransmits whole files, leaks passwords in cleartext, and chokes on flaky links. For any sync, backup, or deploy job, rsync wins on speed, safety, and sanity.
When should you use Ftp?
You're stuck talking to legacy gear, a vendor appliance, or a managed host that literally only speaks FTP and you have no SSH access. That's the only excuse left.
When should you use Rsync?
You're doing anything else — backups, deployments, mirroring directories, or moving large trees over the network. Default to rsync and don't look back.
What's the main difference between Ftp and Rsync?
FTP is a 1970s file-shoveling protocol that sends your credentials in plaintext and copies everything blindly. Rsync diffs, compresses, encrypts over SSH, and resumes. This isn't close.
How do Ftp and Rsync compare on security?
Ftp: Plaintext credentials; FTPS adds TLS but breaks firewalls. Rsync: Runs over SSH — encrypted, key-based, single port. Rsync wins here.
Are there alternatives to consider beyond Ftp and Rsync?
rsync over SSH is the baseline. If you need a browser-friendly web upload UI instead of a sync tool, that's SFTP or object storage, not FTP.
Rsync moves only the bytes that changed, runs over SSH by default, and resumes interrupted transfers. FTP retransmits whole files, leaks passwords in cleartext, and chokes on flaky links. For any sync, backup, or deploy job, rsync wins on speed, safety, and sanity.
Related Comparisons
Disagree? nice@nicepick.dev