FTP vs FTPS vs SFTP in 2026: What to Use, What to Avoid, and Why Plain FTP Still Bites People

Plain FTP sends your username and password across the internet in cleartext. Not encrypted. Not obfuscated. Not hashed. Cleartext. Anyone intercepting network traffic between your machine and the server—your ISP, a compromised router, someone on the same coffee shop Wi-Fi—can read your hosting credentials as easily as reading a text file. In 2026, with free and widely supported secure alternatives available on every hosting platform, there is no defensible reason to use plain FTP for anything. Yet people still do. Every week, hosting support forums field tickets from site owners who discover their password was compromised because their FTP client was configured without encryption and they never noticed.

This guide breaks down the three protocols you will encounter when uploading a static website to a hosting provider: FTP, FTPS, and SFTP. It covers what each one actually does at the protocol level, which one to choose, how to set up secure file transfer on Windows, and where the common pitfalls hide. If you have just finished building a site with a desktop editor and you are ready to publish, this is the part of the workflow that determines whether your credentials stay private or end up in someone else’s hands.

FTP: The Protocol That Should Have Died

File Transfer Protocol dates to 1971. It predates the modern internet. It was designed for a network where security was not a concern because the network itself was small and trusted. FTP establishes a control connection for commands and a separate data connection for file transfers. Neither connection is encrypted.

The implications are straightforward:

• Your password is visible. Login credentials travel in plaintext. Any network-level observer can capture them.
• Your file contents are visible. Every file you upload or download is transferred without encryption. If your site contains configuration files, database credentials in a config file, or client data, all of it is exposed.
• Session hijacking is trivial. Because nothing is authenticated or encrypted after the initial login, an attacker on the same network can inject commands into your FTP session.

Some hosting providers still offer FTP as an option. A few budget hosts still offer it as the only option. If your host falls into the second category, switch hosts. That is not hyperbole. A host that cannot provide SFTP or FTPS in 2026 is signaling that their infrastructure practices are years behind minimum acceptable standards.

Why It Persists

FTP persists for two reasons. First, legacy tooling. Older website builders, automated publishing scripts, and some CMS platforms default to FTP because that is what their upload routines were written for a decade ago and nobody updated them. Second, user inertia. People set up their FTP client once, saved the connection profile, and never revisited the settings. The connection works, files appear on the server, and the security gap is invisible until something goes wrong.

FTPS: FTP with a TLS Wrapper

FTPS (FTP Secure, sometimes called FTP-SSL) adds TLS encryption to the standard FTP protocol. The control connection and data connections are wrapped in TLS, which means your credentials and file contents are encrypted in transit. FTPS comes in two flavors:

Explicit FTPS (FTPES): The client connects on port 21 (standard FTP port) and explicitly requests encryption by sending a STARTTLS command. The server upgrades the connection to TLS. This is the more common and more widely supported mode.

Implicit FTPS: The client connects on a dedicated port (typically 990) where TLS is always required from the first byte. No negotiation step. This mode is older and less commonly offered by modern hosts.

FTPS Strengths

FTPS uses the same underlying protocol as FTP, which means it supports the same commands, directory listing formats, and file transfer modes. If you already know FTP, FTPS feels identical in practice—your client just negotiates encryption before doing anything else. Most hosting control panels (cPanel, Plesk, DirectAdmin) support FTPS out of the box because it layers directly on top of their existing FTP infrastructure.

Certificate validation works the same as HTTPS. The server presents a TLS certificate, your client verifies it, and you get confirmation that you are actually connected to the server you think you are connected to. This prevents man-in-the-middle attacks where someone impersonates your host.

FTPS Weaknesses

FTPS inherits FTP’s multi-connection architecture, and this causes real problems with firewalls and NAT. The control connection on port 21 is straightforward, but the data connections open on dynamic ports that firewalls may block. Passive mode (which most clients use by default) negotiates a port range, but you or your host need to ensure that range is open. Corporate networks, restrictive firewalls, and some home routers can make FTPS connections unreliable.

The dual-connection model also means the TLS negotiation happens multiple times—once for the control channel and once for each data connection. This adds latency, particularly when transferring many small files, which is exactly what a folder-based static website consists of: dozens or hundreds of small HTML, CSS, JavaScript, and image files.

SFTP: The SSH-Based Alternative

SFTP (SSH File Transfer Protocol) is not FTP with encryption bolted on. It is a completely different protocol that runs over SSH (Secure Shell). The name similarity with FTP is unfortunate because it leads people to think SFTP is just another flavor of FTP. It is not. SFTP was designed from scratch as a secure file transfer protocol, and it operates fundamentally differently.

How SFTP Works

SFTP uses a single encrypted connection on port 22 (the standard SSH port). All authentication, commands, and file data travel through this one connection. There is no separate control channel and data channel. There is no dynamic port negotiation. There is no firewall port-range headache.

Authentication can use a password (encrypted within the SSH tunnel), an SSH key pair (more secure, no password transmitted at all), or both (two-factor authentication). Key-based authentication is widely supported and eliminates password-related vulnerabilities entirely.

SFTP Strengths

Single port. Port 22, one connection, no firewall complications. If you can SSH into a server, you can SFTP into it. Corporate firewalls that block FTP’s dynamic ports rarely block SSH.

Strong authentication options. Password plus SSH keys. Certificate-based auth. Multi-factor. SFTP inherits SSH’s full authentication framework, which has been battle-tested for decades.

Consistent behavior. Because everything runs through one connection, transfer reliability is better. No mid-transfer failures because a data connection could not be established. No stalled uploads because a firewall dropped the second connection.

Atomic operations. SFTP supports rename and move operations that are atomic, meaning they either complete fully or not at all. This matters when deploying site updates—you can upload a new version of a file to a temporary name and then atomically rename it, avoiding the window where visitors might see a partially uploaded file.

SFTP Weaknesses

SFTP is not natively supported by every hosting control panel. Budget shared hosting providers sometimes offer only FTP or FTPS through their control panel while making SFTP available only through SSH access that requires separate setup. The protocol is also slightly slower than raw FTP for large file transfers due to the encryption overhead on the single connection, though this difference is negligible for typical website file sizes.

Directory listing formats differ from FTP, which occasionally confuses older tools that expect FTP-style listings. Modern FTP clients handle this transparently, but scripts written to parse FTP output will need adjustment.

Protocol Comparison at a Glance

Feature	FTP	FTPS	SFTP
Encryption	None	TLS	SSH
Default Port	21	21 (explicit) / 990 (implicit)	22
Connections	Multiple	Multiple	Single
Firewall Friendly	Moderate	Poor	Good
Password Security	Cleartext	Encrypted	Encrypted
Key-Based Auth	No	Rare	Yes
Hosting Support	Universal	Wide	Wide

Which One Should You Use?

Use SFTP if your host supports it. It is the most secure, most firewall-friendly, and most reliable option. Virtually all VPS and dedicated server hosting supports SFTP. Most quality shared hosting providers support it as well. Check your hosting control panel for SSH access or SFTP credentials.

Use Explicit FTPS if SFTP is unavailable. If your host only offers FTP-based access, ensure you are using Explicit FTPS (FTPES) rather than plain FTP. Your FTP client should show a TLS lock icon or certificate confirmation when connecting.

Never use plain FTP. There is no scenario in 2026 where plain FTP is the correct choice. If your client software defaults to FTP, change the setting. If your host only supports FTP, change the host.

Setting Up Secure File Transfer on Windows

Recommended Windows FTP/SFTP Clients

WinSCP is the best free SFTP client for Windows. It supports SFTP, FTPS, SCP, and plain FTP (though you should never use that last one). The interface provides a dual-pane file manager with your local files on the left and the remote server on the right. Drag-and-drop transfers, synchronization features, and a scripting interface for automated uploads make it suitable for everything from one-off transfers to scheduled publishing workflows.

FileZilla is the most widely known free FTP client. It supports FTP, FTPS, and SFTP. The interface is functional if not elegant, and it handles large transfer queues well. One important note: download FileZilla only from the official site (filezilla-project.org). Third-party download sites have historically bundled adware with the installer.

Cyberduck supports SFTP, FTPS, and a wide range of cloud storage protocols (S3, Google Cloud Storage, Azure Blob). It is a good choice if you publish to both traditional hosting and cloud storage platforms.

Configuring a Connection

Regardless of which client you choose, the setup process follows the same pattern:

1. Get your credentials from your host. Your hosting control panel will provide a hostname (often your domain name or a server-specific hostname), a username, a password, and optionally an SSH key. Note which protocol the host supports—the credentials section will usually say “SFTP” or “FTP/FTPS.”

2. Create a new connection profile. In your FTP client, create a new site entry. Set the protocol to SFTP (preferred) or Explicit FTPS. Enter the hostname, port (22 for SFTP, 21 for FTPS), username, and password.

3. Verify the server fingerprint or certificate. On first connection, the client will display the server’s SSH fingerprint (SFTP) or TLS certificate (FTPS). Verify this matches what your host provides. Accept it to continue. This step prevents man-in-the-middle attacks.

4. Navigate to your web root. Once connected, navigate to the directory where your website files belong. On shared hosting this is typically public_html/ or www/. On some platforms it may be htdocs/ or simply /.

5. Upload your site folder. Select your local site files and transfer them to the remote web root. The folder structure you built locally should be replicated exactly on the server.

Common Pitfalls

Defaulting to FTP without realizing it. Some FTP clients default to plain FTP when you create a new connection. Always explicitly select SFTP or FTPS in the protocol dropdown. Do not assume the client will automatically negotiate encryption.

Saving passwords in the client without master password protection. FileZilla and WinSCP both offer to save your connection passwords. If you do this without setting a master password, anyone with access to your Windows account can extract your hosting credentials from the client’s configuration files. Use a master password or rely on your operating system’s credential manager.

Uploading to the wrong directory. Your web root is not the same as your account root. If you upload files to / instead of /public_html/, your site will not appear. If you upload them inside an extra nested folder (creating /public_html/my-site/ instead of putting files directly in /public_html/), your URLs will have an unwanted prefix.

Overwriting files without backup. Before uploading an updated version of your site, consider downloading the current live version first. If something goes wrong with the update, you have an immediate rollback path. This is basic operational hygiene that many people skip until they need it.

Ignoring file permissions. Linux-based hosting servers use file permissions that determine who can read, write, and execute files. HTML files typically need 644 permissions (owner read-write, group and public read-only). Directories need 755. If your uploaded files are not accessible, check permissions through your FTP client’s properties panel.

How This Connects to Your Publishing Workflow

If you are building a site with a desktop editor like DFM2HTML, the export step gives you a complete folder of static files on your hard drive. Publishing that site means transferring those files to your host using one of the protocols above. The folder structure guide covers how to organize those files before upload. This guide covers how to get them to the server securely.

The full tutorials section will continue expanding with guides on migration, versioning, and other publishing workflow topics throughout 2026. Each builds on the same foundation: a clean folder of static files, a secure transfer method, and a hosting platform that serves them to visitors. There are no build steps, no deployment pipelines, and no CI/CD configurations to maintain. You build locally, you upload securely, and your site is live.

That simplicity is the entire point. A static site built with a desktop editor and published via SFTP has a deployment workflow that you can explain in two sentences and execute in under a minute. The security part—choosing SFTP over FTP, verifying server fingerprints, protecting saved credentials—adds about thirty seconds of setup and then protects you for every subsequent upload. There is no reason to skip it.