What is FTP? A Practical Explainer

FTP stands for File Transfer Protocol — the network standard for moving files between two computers over TCP/IP. It was specified in RFC 114 in 1971, predating HTTP, email-as-we-know-it, and the World Wide Web by decades. An FTP server hosts files; an FTP client connects to the server, logs in with a username and password, and uploads or downloads files. That's the whole job. The rest of this post explains how FTP actually works under the hood, why it has the quirks it does, where it's still in use in 2026, and what most teams have replaced it with.

What does FTP stand for?

File Transfer Protocol. The full name is descriptive, not a marketing acronym — FTP does exactly one thing: move files. Three letters, no creative license.

FTP runs on top of TCP (Transmission Control Protocol), which is the reliable-delivery layer of the internet. TCP guarantees that bytes sent by the FTP client arrive at the FTP server in order and without corruption. If a packet drops on the network, TCP retransmits; FTP doesn't have to know. That layering is the reason FTP works reliably across long, lossy network paths.

How FTP works under the hood

The mechanical answer to "how does FTP work" comes down to two design choices made in 1971 that still drive every FTP question you'll have today.

FTP separates control from data. Instead of sending file bytes over the same connection as the login and command traffic, FTP uses two TCP connections:

• The control connection on port 21 carries the login, the directory navigation, and the transfer commands.
• The data connection carries the actual file bytes. It uses port 20 in active mode, or an ephemeral high port chosen by the server in passive mode.

The dual-channel design made sense when networks had no firewalls and every host had a public IP. Today it's the reason FTP is harder to firewall than newer protocols.

FTP is cleartext. FTP was specified before TLS existed. Usernames, passwords, commands, and file contents all travel over the network as plain text. Anyone on the network path between client and server can read everything. This is the reason SFTP (SSH-based, encrypted) and FTPS (FTP wrapped in TLS) exist — see our FTP vs FTPS vs SFTP explainer for the full comparison.

The exchange between an FTP client and server looks roughly like this on the control channel:

Client → Server:  USER alice
Server → Client:  331 Password required
Client → Server:  PASS s3cret
Server → Client:  230 Login successful
Client → Server:  PASV
Server → Client:  227 Entering Passive Mode (10,0,0,5,195,80)
Client → Server:  RETR report.csv
Server → Client:  150 Opening data connection
                  [file bytes flow on the data channel]
Server → Client:  226 Transfer complete

The numbered responses (230, 227, 226) are FTP's status codes, conceptually similar to HTTP's 200/404/500 — but FTP got there first.

How FTP authentication works

Plain FTP supports one authentication model: username and password. The client sends both over the control channel in cleartext, and the server checks them against its local user database. There are no API tokens, no SSO, no key-based auth, no multi-factor — just a username and password, exactly as in 1971.

A common variation is anonymous FTP, where the server accepts the username anonymous (or ftp) with any password — typically an email address by convention. Public software-mirror sites have used anonymous FTP for decades; it's how a lot of open-source projects distributed releases before HTTP became the default.

For anything that needs real authentication in 2026, plain FTP isn't the right tool. SFTP (a subsystem of SSH) supports key-based authentication and is the modern default. FTPS adds TLS to FTP and at least encrypts the password in transit, but still uses the username/password model underneath.

What FTP commands look like

FTP started its life as a command-line tool, and the original ftp command is still shipped on most Unix-like systems plus Windows. A session looks like this:

$ ftp ftp.example.com
Connected to ftp.example.com.
220 Welcome
Name (ftp.example.com:alice): alice
331 Password required
Password: ********
230 Login successful
ftp> cd /reports
250 Directory changed
ftp> ls
200 PORT command successful
150 Opening ASCII mode data connection
-rw-r--r-- 1 alice users  12345 May 24 09:00 report.csv
226 Transfer complete
ftp> get report.csv
local: report.csv remote: report.csv
200 PORT command successful
150 Opening BINARY mode data connection
226 Transfer complete
ftp> bye
221 Goodbye

The most-used FTP commands are cd (change directory), ls (list files), get (download), put (upload), mget / mput (multiple files), binary and ascii (transfer mode), and bye (quit). See our essential FTP commands cheat sheet for the full reference.

In practice, almost no one uses the command-line ftp tool anymore. Graphical FTP clients — FileZilla, WinSCP, Cyberduck, Transmit — replaced the CLI experience years ago, and most users on a modern desktop have never opened a terminal to transfer a file.

What businesses still use FTP for

In 2026, FTP is mostly a compatibility bridge rather than a fresh design choice. The places where it still shows up:

• EDI and B2B file exchange. Decades-old supply-chain integrations between manufacturers, distributors, and retailers run on FTP because that's how the partnership was wired in 1995 and the cost of rewriting is higher than the cost of keeping it running.
• IoT and industrial equipment. Security cameras, kiosks, scanned-document terminals, scientific instruments, retail POS systems — many ship with FTP support baked in, with no realistic upgrade path.
• Healthcare and financial back-office workflows. Older claims-processing systems, batch financial reporting, scanned-document intake pipelines. Heavily regulated; risk-averse about changing what already works.
• Bulk media transfer in advertising and broadcast. Large file delivery between agencies, post-production houses, and broadcasters — historically FTP-shaped, slowly moving to S3-shaped APIs.
• Open-source software distribution. A few archives still maintain anonymous FTP mirrors alongside HTTPS, mostly for historical reasons.

What FTP is not the right tool for in 2026: any new design with sensitive data, any workflow that needs audit logging, any partner exchange where you don't fully control both endpoints, any integration that would benefit from a REST API.

Why FTP feels harder than it should

Most of the day-to-day friction around running FTP isn't with the protocol itself — it's with the operational surface around it:

• Firewall and NAT pain. The dual-channel design means firewalls have to allow the control port (21) plus a passive-mode port range. Half the FTP support tickets in the world are some variant of "I can log in and list the directory but the file transfer hangs." That's the data channel failing through a firewall.
• No native encryption. Plain FTP sends credentials in cleartext. Adding encryption means moving to FTPS or SFTP, each with its own configuration story.
• Manual user and credential management. Adding a partner, rotating a password, revoking access — each is a shell-script administrative task on the server.
• Audit logging. Stitching vsftpd.log into a SOC 2 evidence trail is possible but more work than any auditor will be happy with.
• Compliance ownership. If you run an FTP server in your own infrastructure, every compliance question (SOC 2, HIPAA, PCI, GDPR) is your scope.

These costs are why most teams running FTP-shaped workflows have moved to managed-file-transfer platforms that handle the protocol layer and the operational surface together.

The modern way to "do FTP"

Files.com is the File Orchestration Platform we'd recommend for any team running FTP, FTPS, or SFTP workflows in 2026. It exposes the protocols on their standard ports on a subdomain Files.com provisions for you, so your trading partners can keep using whatever FTP client they already have — but the server side is fully managed:

• FTP (port 21), FTPS (21 + 990), SFTP (port 22), and WebDAV all on one platform. One endpoint, four protocols, your partners pick.
• Passive mode auto-configured. No port ranges to open on your firewall.
• TLS certificates managed automatically. Provisioned and renewed; modern cipher suites by default.
• Per-user credentials, SSH key auth, MFA, audit logging. The things FTP alone never gave you.
• REST API, SDKs in 8 languages, AS2 partner messaging, automation workflows. The things FTP infrastructure was never designed to do.
• SOC 2 Type II and HIPAA-BAA out of the box. Compliance posture comes pre-built, not as your scope.
• A real browser-based file manager exposes the same files as the protocols. Drag-and-drop, share links, password-protected and expiring links — the workflow FTP alone was never going to give you.

Start a free Files.com trial — no credit card, provisioned in about 10 minutes. Point your existing FTP clients at the subdomain; the platform handles the rest.

For the narrow set of teams that must run file-transfer infrastructure inside their own datacenter — air-gapped environments, strict data-residency mandates, regulated workloads that prohibit multi-tenant cloud — the free ExaVault on-premise appliance handles FTP / FTPS / SFTP / WebDAV from a self-hosted VM image.

FAQ

What does FTP stand for?

FTP stands for File Transfer Protocol. It's a network protocol for moving files between two computers over TCP/IP, specified in RFC 114 (1971) and reaching its modern form in RFC 959 (1985).

What is an FTP server?

An FTP server is a piece of software running on a host that listens on TCP port 21 for incoming FTP connections. Clients connect, authenticate, and upload or download files from the server's filesystem. Popular open-source FTP servers include vsftpd, ProFTPD, and FileZilla Server.

What is an FTP client?

An FTP client is the software you use to connect to an FTP server. Common clients include FileZilla (free, cross-platform), WinSCP (free, Windows), Cyberduck (free, Mac), and Transmit (paid, Mac). Most modern operating systems also ship with a ftp command-line tool that does the same job with a terminal interface.

What port does FTP use?

FTP uses port 21 for the control connection (login, commands) and either port 20 (active mode) or a server-assigned high port (passive mode) for the data connection. See our deep-dive on FTP ports for the firewall implications.

Is FTP secure?

Plain FTP is not secure — it sends usernames, passwords, and file contents over the network in cleartext. For anything sensitive, use SFTP (port 22, SSH-based) or FTPS (port 21 with TLS). See the full comparison.

Can I use FTP in a web browser?

No, not anymore. Chrome removed FTP support in version 88, Firefox in 90, and Safari has been FTP-free for years. See how to access an FTP server from the browser today for the modern paths.

What's the difference between FTP and HTTP?

Both move data over TCP, but for different jobs. HTTP is a request/response protocol designed for the web — one connection per request, optimized for hypertext documents and now everything else. FTP is a stateful protocol designed for bulk file transfer — persistent control connection, separate data channel, directory navigation, transfer-mode flags. For website traffic, HTTP wins decisively. For server-to-server file delivery between partners, FTP held on for a long time because it was specifically built for that shape — though SFTP and modern REST APIs have largely replaced it in new deployments.

Why is FTP still around if it's old and insecure?

Installed-base inertia. Decades of equipment, vendor integrations, partner workflows, and back-office automation already speak FTP. The cost of upgrading the long tail of FTP-only systems is higher than the cost of running the protocol behind enough network controls to manage the risk. Most teams running FTP today are doing so as a compatibility bridge, not as a new design choice.