What Is FTP and How Does It Work? FTP vs SFTP vs FTPS Explained (2026)

Almost everyone who has ever managed a website, moved files between servers, or administered IT infrastructure has run into three little letters: FTP. Yet few people outside technical circles understand what FTP is and how it works — and even fewer realize that the “S” variants most hosts recommend today are completely different technologies hiding behind nearly identical names. This guide explains the File Transfer Protocol from the ground up: how it moves your files, why its 1971 design makes it unsafe on the modern internet, and how its secure successors — FTPS and SFTP — actually differ from each other.

What Is FTP? The Original File Transfer Protocol

FTP stands for File Transfer Protocol, and it is one of the oldest protocols still in regular use on computer networks. First specified in 1971 — before the World Wide Web existed, before email was standardized, and roughly a decade before the domain name system — FTP was created to solve a simple problem: how do you copy a file from one computer to another over a network?

The answer the protocol’s designers came up with was a client–server architecture. An FTP client (software such as FileZilla, WinSCP, or even a command-line tool) connects to an FTP server (software running on the machine that holds the files). Once authenticated with a username and password, the client can browse the server’s directories, upload files, download files, rename them, delete them, and create new folders.

For decades, FTP was the standard way to publish a website: you designed pages on your own computer, opened your FTP client, and uploaded them to your web host’s server. It was also widely used inside companies to exchange large datasets, distribute software, and back up systems. Understanding what FTP is and how it works still matters today, because the protocol’s descendants power an enormous amount of behind-the-scenes file movement — and because using plain FTP on the public internet is one of the easiest security mistakes a person or business can make.

How FTP Works: The Two-Channel Architecture

The single most important thing to understand about how FTP works is that it does not use one connection between the client and the server. It uses two — a design choice that made sense in 1971 but causes most of the protocol’s modern headaches.

The Control Channel (Port 21)

When your FTP client first connects to a server, it opens a control connection on TCP port 21. This channel carries commands and replies, not file data. It is essentially a conversation: the client sends short text commands such as USER (identify the account), PASS (supply the password), PWD (show the current directory), LIST (show directory contents), CWD (change directory), RETR (download a file), and STOR (upload a file). The server answers each command with a numeric status code and a human-readable message — for example, 230 means “login successful” and 226 means “transfer complete.”

This command channel stays open for the whole session. Everything you do in the client — clicking through folders, starting uploads — is translated into these short commands behind the scenes.

The Data Channel (Port 20 and Dynamic Ports)

Here is the unusual part: actual file contents and directory listings do not travel over the control channel. Every time a transfer is needed, a second connection — the data connection — is opened, used for that one transfer, and then closed. In the protocol’s original “active” mode, the data connection originates from the server’s port 20 back toward the client.

This two-channel split is the root of FTP’s reputation for firewall trouble. Firewalls must allow not only port 21 but also the dynamically negotiated data ports, and the negotiation itself looks suspicious to security equipment that inspects traffic. Network address translation (NAT), which nearly every home and office router performs, further complicates matters because the addresses the client and server exchange inside FTP commands may not match the real, translated addresses.

Active Mode vs Passive Mode

To work around these problems, FTP supports two connection modes:

• Active mode is the original design: the client tells the server which port to connect back to, and the server initiates the data connection to the client. This fails whenever the client sits behind a firewall or NAT router that blocks unexpected inbound connections — which is nearly always the case today.
• Passive mode flips the direction: the server tells the client a port to connect to, and the client opens the data connection to the server. Because the client initiates both connections, passive mode passes through client-side firewalls and NAT far more reliably. Passive mode is the default in virtually every modern FTP client, and if you have ever had an FTP transfer mysteriously hang, switching between active and passive mode is the first thing to try.

Even in passive mode, the server must expose a range of passive data ports through its own firewall, so server administrators still have configuration work to do. The two-channel architecture is a permanent source of complexity — and it is one reason newer protocols abandoned it.

The Fatal Flaw: Why Plain FTP Is Not Secure

Everything about classic FTP happens in cleartext. Your username, your password, the commands you send, and the files you transfer are all transmitted across the network unencrypted. Anyone positioned between your computer and the server — on the same public Wi-Fi network, at a compromised router, or running a network sniffer on a shared segment — can read your credentials and your data as easily as reading a postcard.

In 1971, when networks were small, closed, and run by trusted institutions, this was an acceptable trade-off. On the modern internet it is not. This is why:

• Credential theft: a captured FTP password often grants access not only to file storage but to web hosting accounts, where an attacker can deface websites or plant malware.
• Data exposure: files containing customer records, financial data, or intellectual property travel in the open.
• Tampering: without integrity protection, transferred files can be modified in transit without either side noticing.
• Compliance failure: regulations such as HIPAA, PCI-DSS, GDPR, CCPA, and SOC 2 require encryption of data in transit. Plain FTP cannot satisfy any of them, which disqualifies it from healthcare, payment, and most enterprise environments.

The practical rule is simple: never use plain FTP over the public internet. On a trusted local network, or with legacy equipment that supports nothing else, it may still have a place — but anything crossing the internet needs one of the encrypted alternatives described below.

FTPS: FTP Wrapped in TLS Encryption

FTPS — full name FTP Secure, technically FTP over SSL/TLS — is exactly what the name suggests: the original FTP protocol with a TLS encryption layer bolted on. Every command, credential, and file is encrypted using the same TLS technology that protects HTTPS websites. Underneath the encryption, however, it is still FTP: the two-channel architecture, the active and passive modes, and the firewall complexity all remain.

Explicit FTPS vs Implicit FTPS

FTPS comes in two flavors, and you need to know which one your server expects:

• Explicit FTPS starts as an ordinary unencrypted FTP connection on port 21. The client then issues an AUTH TLS command, and both sides upgrade the connection to TLS. Because it begins on the standard FTP port, explicit mode is the more common and more flexible option — servers can even support both plain and encrypted clients on the same port.
• Implicit FTPS assumes TLS from the very first byte, conventionally on port 990, with no negotiation step. It is older, less common, and largely retained for compatibility with legacy systems.

FTPS encrypts both the control and data channels, but each channel needs its own TLS handshake, which adds configuration complexity. It is a reasonable upgrade path when an organization already has FTP infrastructure, or when a business partner specifically requires FTPS. For brand-new deployments, though, most engineers reach for the next option instead.

SFTP: The SSH-Based Protocol That Is Not FTP at All

Here is the twist that confuses almost everyone: SFTP is not a secure version of FTP. Despite the name, SFTP — the SSH File Transfer Protocol — is a completely separate protocol built on top of SSH (Secure Shell), the same encrypted technology administrators use to log into servers remotely. It shares nothing with FTP except the general idea of moving files.

Because SFTP runs inside a single SSH session, it avoids FTP’s defining weakness:

• One connection, one port: SFTP uses a single encrypted tunnel — conventionally TCP port 22, the SSH port — for commands, authentication, and file data alike. No second channel, no dynamic data ports, no firewall gymnastics.
• Encryption by default: everything, including credentials and directory listings, is encrypted by SSH. There is no unencrypted mode to fall back into by accident.
• Strong authentication: SFTP natively supports SSH key-based authentication, which is far stronger than passwords and enables automated, passwordless transfers for scripts and scheduled jobs.
• Full file management: beyond uploads and downloads, SFTP supports remote file permissions, symbolic links, and directory operations as part of the protocol.

When hosting documentation tells you to “use SFTP,” it means this SSH-based protocol — not FTP with security added. The two are incompatible: an FTP client configured for port 21 will never connect to an SFTP server on port 22, and vice versa. Also note that a server offering SSH shell access does not automatically offer SFTP; the SFTP subsystem must be enabled on the server side.

FTP vs SFTP vs FTPS: The Differences That Actually Matter

With the background in place, here is the head-to-head comparison most people are really looking for when they ask what FTP is and how it works:

• What it is: FTP is the original 1971 cleartext protocol. FTPS is FTP with TLS encryption added. SFTP is an unrelated SSH-based protocol.
• Encryption: FTP has none. FTPS uses TLS/SSL. SFTP uses SSH encryption.
• Ports: FTP uses 20 and 21. FTPS uses 21 (explicit) or 990 (implicit) plus a passive data-port range. SFTP uses 22 only.
• Connections: FTP and FTPS open separate control and data connections. SFTP multiplexes everything through one connection.
• Firewall setup: FTP and FTPS require multiple ports and ranges, which is painful through NAT. SFTP needs a single port.
• Authentication: FTP and FTPS use passwords (FTPS can also use client certificates). SFTP supports passwords and SSH keys natively.
• Compliance: FTP fails HIPAA, PCI-DSS, GDPR, and SOC 2 encryption requirements. FTPS and SFTP can satisfy them when configured correctly.

For a new deployment in 2026, the professional consensus is clear: choose SFTP unless a specific partner, client, or legacy system forces you onto FTPS. SFTP needs one firewall rule instead of several, authenticates with keys, and if your server already runs SSH, the infrastructure is already in place. Choose FTPS when an existing FTP setup or a vendor specification demands it. Choose plain FTP only on isolated, trusted networks — never on the internet.

Is FTP Still Used in 2026?

Yes — more than you might expect, though its territory keeps shrinking. Plain FTP survives in a few specific niches:

• Legacy systems: industrial equipment, old printers, medical devices, and embedded systems whose firmware only speaks FTP.
• Internal networks: fast, simple bulk transfers between machines on a trusted LAN where encryption overhead and complexity buy little.
• Anonymous download servers: public software mirrors and archives that historically offered anonymous FTP access (increasingly replaced by HTTPS).

Everywhere else, the migration is long finished. Web hosts moved to SFTP years ago. Enterprises moving files between companies now use SFTP, FTPS, HTTPS-based APIs, or managed file transfer platforms that add auditing, automation, and guaranteed delivery on top of the raw protocols. The trajectory is one-directional: plain FTP on the public internet is a legacy practice, not a current recommendation.

How to Use FTP and SFTP Safely: Practical Tips

If you need to transfer files with these protocols — for web hosting, server administration, or business data exchange — follow these practices:

• Prefer SFTP always. In your client (FileZilla, WinSCP, Cyberduck, or the command line), select the SFTP protocol and port 22 rather than FTP on port 21.
• Use SSH keys instead of passwords for SFTP wherever possible. Generate a key pair, keep the private key secret, and install the public key on the server. Keys resist brute-force attacks that passwords invite.
• Verify the server’s identity on first connection. SFTP clients show a host key fingerprint; confirm it through a trusted channel before accepting, to defeat man-in-the-middle attacks.
• Never enter FTP credentials on public Wi-Fi unless the connection is encrypted (SFTP or FTPS). Plain FTP credentials on a coffee-shop network are an invitation to account takeover.
• Use passive mode if you must use FTP or FTPS, and ask the server administrator for the passive port range so firewalls can be configured correctly.
• Restrict accounts with least privilege: give transfer accounts access only to the directories they need, never the whole server.
• Keep server software updated. FTP and SSH servers have had serious vulnerabilities over the years; unpatched servers are a common breach vector.
• Log and monitor transfers involving sensitive data, so unusual activity — large unexpected downloads, odd hours — gets noticed.

Beyond FTP: Modern Alternatives Worth Knowing

FTP’s family is not the only way to move files. Depending on your needs, one of these may fit better:

• HTTPS uploads and downloads: the simplest option for sharing files with non-technical users — a web link, no special client required. Services built on HTTPS also benefit from the web’s mature encryption and authentication.
• WebDAV: an extension of HTTP that lets you mount remote storage as a local drive, useful for collaborative document editing.
• rsync over SSH: the administrator’s favorite for synchronizing large directory trees efficiently, transferring only changed blocks.
• Cloud storage sync (Dropbox, Google Drive, OneDrive, Nextcloud): effortless for teams, with versioning and sharing links built in — though you trade control for convenience.
• Managed file transfer (MFT) platforms: for businesses exchanging files with partners under compliance obligations, MFT adds encryption, automation, audit trails, and delivery guarantees around the core protocols.

Each alternative solves a different slice of the file-sharing problem. The protocols you choose should follow from your requirements for security, automation, and ease of use — not from habit.

Frequently Asked Questions

What does FTP stand for?

FTP stands for File Transfer Protocol. It is a standard network protocol, dating to 1971, used to transfer files between a client and a server over a network.

Is SFTP just secure FTP?

No — this is the most common misconception. SFTP (SSH File Transfer Protocol) is a completely different protocol that runs over SSH. FTPS is the actual “FTP with security added.” The names are confusingly similar, but the technologies are unrelated and incompatible.

What port does FTP use?

Classic FTP uses TCP port 21 for the control connection and port 20 for data in active mode. FTPS uses port 21 (explicit) or 990 (implicit). SFTP uses port 22, the SSH port.

Is FTP safe to use?

Plain FTP is not safe on the public internet because everything — including your password — is transmitted unencrypted. Use SFTP or FTPS instead, and reserve plain FTP for trusted local networks or legacy equipment.

Which is better: SFTP or FTPS?

Both encrypt transfers effectively when configured correctly. SFTP is generally the better default: it uses a single port, works cleanly through firewalls, and supports SSH key authentication. Choose FTPS when an existing system or partner specifically requires it.

Conclusion

Understanding what FTP is and how it works means understanding a piece of internet history that never quite went away. The File Transfer Protocol’s two-channel design — a control connection on port 21 plus on-demand data connections — was elegant in 1971 and is the source of nearly every FTP headache today, from firewall configuration to the cleartext transmission of passwords. FTPS kept the design and added TLS encryption; SFTP discarded the design entirely in favor of a single SSH-encrypted tunnel.

The practical takeaway is straightforward: retire plain FTP for anything that crosses the internet, default to SFTP for new work, and keep FTPS in your toolkit for the partners and legacy systems that require it. File transfer may be one of computing’s oldest problems, but with the right protocol choice, it does not have to be one of its riskiest.