You've probably used FTP without realizing it. That time you uploaded a theme to WordPress? In real terms, the developer who sent you a massive zip file via a "secure link" that opened in a browser? FTP. Also FTP — just wearing a trench coat.
It's everywhere. And yet most people couldn't explain what it actually does if their hosting renewal depended on it.
What Is FTP
File Transfer Protocol. Also, that's the name. But the name tells you almost nothing about what it actually is And that's really what it comes down to..
At its core, FTP is a standard network protocol for moving files between a client and a server over TCP/IP. That's the textbook version. Here's the human version: it's a way to copy files from your computer to someone else's computer — or vice versa — across the internet, with a structure that lets you work through folders, resume broken transfers, and handle files too big for email And that's really what it comes down to. And it works..
It predates the web. Day to day, the protocol we use today (RFC 959) landed in 1985. RFC 114 was published in 1971. Even so, hTTP didn't show up until 1991. So when you're dragging a folder into FileZilla, you're using technology older than the World Wide Web itself.
The two-channel design
This is the part most explanations skip. FTP uses two connections:
- Command channel (port 21) — stays open the whole session. You send commands here: LIST, RETR, STOR, DELE. The server replies with status codes.
- Data channel — opens per transfer. Every file listing, every upload, every download gets its own temporary connection.
That split design causes headaches with firewalls and NAT. We'll get to that.
Active vs. passive mode
In active mode, the client tells the server "connect back to me on port X" for the data channel. The server initiates that connection. Great in 1985. Terrible today — your router blocks unsolicited inbound connections.
Passive mode flips it. The client asks "where should I connect for data?" The server replies with an IP and port. The client initiates both connections. This is why passive mode is the default everywhere now.
Why It Matters / Why People Care
You might think: "I have SFTP, rsync, S3, Google Drive. Why does FTP still exist?"
Because it solves specific problems nothing else quite does the same way.
It handles huge transfers without choking
Try uploading a 50 GB site backup via a browser-based file manager. It'll time out. Practically speaking, split into chunks? That's why maybe. Resume after a network blip? Good luck.
FTP clients (the good ones) support resume and restart natively. The protocol has a REST command. So you say "start at byte 1,048,576" and the server picks up exactly there. No re-uploading the first 99%.
It's scriptable. Really scriptable.
open ftp.example.com
user deploy
pass ********
binary
put build.tar.gz /var/www/releases/
bye
Save that as a text file. txtfrom a cron job. Done. Just works. On top of that, no API keys, no SDKs, no OAuth dance. Runftp -s:deploy.That's why CI/CD pipelines still use it for simple deployments.
Universal support
Every OS ships with an FTP client. But windows, macOS, Linux, *BSD — even embedded devices. Most hosting control panels (cPanel, Plesk, DirectAdmin) expose FTP by default. You don't need to install anything on the server side Not complicated — just consistent..
Anonymous access for public distribution
Kernel mirrors. Linux ISOs. But scientific datasets. The anonymous user with an email-as-password convention lets anyone download without an account. Try doing that securely with S3 without presigned URLs and IAM policies Took long enough..
How It Works (or How to Do It)
Let's walk through a real session. Not the abstract version — what actually happens when you connect.
1. The handshake
You point your client at ftp.example.com:21. The server responds:
220 ProFTPD 1.3.7 Server ready.
That 220 is a status code. On top of that, three digits. First digit = category (2 = success). The rest = detail It's one of those things that adds up..
2. Authentication
USER alice
331 Password required for alice
PASS ********
230 User alice logged in
Plain text. Anyone sniffing the wire sees the password. Think about it: over port 21. This is why plain FTP is dead for anything sensitive. Use FTPS (FTP over TLS) or SFTP (SSH File Transfer Protocol — completely different protocol, despite the name) No workaround needed..
3. Setting transfer mode
TYPE I
200 Type set to I
TYPE I = binary (image) mode. Which means TYPE A = ASCII mode, which does line-ending conversion (CRLF ↔ LF). Almost never use ASCII mode anymore. It corrupts binaries. Just use binary for everything.
4. Passive mode negotiation
PASV
227 Entering Passive Mode (203,0,113,10,195,42)
The server gives you an IP (203.So 0. 113.That said, 10) and a port (195×256 + 42 = 49,962). Your client connects to that for the data channel.
5. The actual transfer
RETR backup.sql.gz
150 Opening BINARY mode data connection for backup.sql.gz (2.1 GB)
226 Transfer complete
The 150 means "data connection open, transfer starting." The 226 means "done, data connection closed."
6. Directory operations
CWD /var/www/html
250 CWD command successful
LIST
150 Here comes the directory listing
-rw-r--r-- 1 alice users 1245184 Jan 12 14:22 index.php
drwxr-xr-x 2 alice users 4096 Jan 10 09:11 images
226 Directory send OK.
LIST returns human-readable output. MLSD (machine-readable) is better for scripts — standardized format, parsable.
Common Mistakes / What Most People Get Wrong
Treating FTP as secure
It's not. Credentials in cleartext. On top of that, **Never use plain FTP over the public internet. Commands in cleartext. Data in cleartext. ** Not for admin. Not for backups. Not for anything you care about Small thing, real impact..
FTPS (explicit TLS on port 21, implicit on 990) fixes this. In practice, only on a trusted LAN. SFTP fixes this differently. But plain FTP? Maybe.
Using ASCII mode for everything
"I'll just use ASCII to be safe.That's it. On top of that, use binary. " No. This leads to you'll corrupt every image, zip, PDF, and binary. ASCII mode converts line endings. Always That alone is useful..
Ignoring passive mode port ranges
Your server sits behind a firewall. Worth adding: you enable passive mode. But the server picks random high ports for each data connection That's the part that actually makes a difference. But it adds up..
7. Firewall and passive mode port ranges
The server’s response to PASV includes a port number calculated as 195×256 + 42 = 49,962. Consider this: if your server is behind a firewall that blocks outbound connections (or restricts incoming ones), the client won’t be able to establish the data channel. To fix this, configure the server to use a predefined range of ports for passive mode, like 50000-50100, and open those in your firewall rules. Without this, passive mode often fails silently or with cryptic errors like "425 Can't open passive connection.
8. Ignoring timeouts and keep-alive
FTP connections can drop if idle for too long. That's why servers and clients often have default timeouts (e. g.That said, , 60 seconds). For large file transfers or long-running sessions, configure keep-alive commands (NOOP) to prevent disconnection. Many clients send periodic NOOP to keep the control channel alive, but this must be explicitly enabled Easy to understand, harder to ignore..
9. Misusing LIST in scripts
While LIST returns human-readable output, parsing it in scripts is error-prone due to inconsistent formatting across servers. Worth adding: use MLSD instead, which returns standardized machine-readable entries with predictable fields (e. g.On top of that, , file size, timestamps). This avoids bugs caused by variations in date formats or permissions.
10. Overlooking encryption entirely
Even with FTPS, misconfiguration can lead to plaintext fallbacks. That's why for SFTP, verify the server supports the correct SSH version and key exchange algorithms. Ensure your client enforces TLS and rejects unencrypted connections. Never assume "secure" defaults—explicitly configure encryption settings.
Conclusion
FTP remains a relic of the early internet, riddled with design flaws that modern protocols like SFTP and HTTPS have long since resolved. Think about it: while its simplicity makes it easy to implement, its lack of security and quirky behavior (like ASCII mode and passive mode port handling) demand careful attention. Plus, for critical operations, avoid plain FTP altogether. Plus, when you must use it, enforce binary mode, configure passive port ranges, and layer on TLS. Better yet, migrate to SFTP or HTTPS-based file transfers—your future self (and security team) will thank you That's the part that actually makes a difference. Nothing fancy..
