Tool

Compare transfer protocols

Use the checkboxes to hide protocols you do not need and the aspect list to focus the notes. The table itself stays complete.

In the Windows client documented at winscp.net, these are selected from the Login dialog. FTPS is not its own entry in the File protocol list: you choose FTP, then an explicit or implicit TLS method. SFTP and SCP are separate SSH protocols that happen to share port 22. S3 is an object API. The product’s own protocol article is the long-form reference for behavior that differs by server version.

Supported protocols, on the developer’s site (opens winscp.net in a new tab)

Protocols to show

Aspect

Encryption protects the session from eavesdropping. It does not prove you reached the right server. FTP without TLS has no encryption. FTPS, SSH protocols, HTTPS WebDAV, and Amazon S3 over HTTPS do, in different ways.

Comparison of file transfer protocols
Aspect	SFTP	FTP	FTPS	SCP	WebDAV	S3
Security	The connection is encrypted by SSH, including the login and the file data. Encryption does not decide whether you are talking to the right server. The host key check does that.	Basic FTP does not encrypt the username, the password, or the files. Anyone who can observe the network path can read them. “FTP” by itself should not be described as a secure protocol. A TLS-protected variant is FTPS, configured separately.	FTPS adds TLS to FTP. In explicit mode this client requests encryption for both the control channel and the data channel for the whole session. Implicit mode encrypts the entire session from the start. A certificate check is still required; encryption with the wrong server protects nothing important.	SCP is encrypted by SSH and uses the same host-key check as other SSH sessions. The encryption is real. The protocol is still a poor fit for browsing and for careful synchronization.	WebDAV is an HTTP extension. It is encrypted only when you select the HTTPS form and the certificate is the right one. Plain HTTP WebDAV sends credentials and file data in the clear, much like plain FTP.	The client talks to S3 through the REST interface over HTTPS. Network encryption still depends on using that secure connection and on the endpoint certificate. Access is then decided by the keys and the bucket policy.
Authentication	Username and password, a public key, keyboard-interactive prompts, an agent, and GSSAPI or Kerberos are all possible. The server decides which methods are offered.	Accounts use a username and password. Public servers may offer anonymous login, which is still unencrypted. FTP does not use SSH keys.	Username and password are typical. Some servers also require a TLS client certificate. SSH keys are not the credential for FTPS.	The SSH methods apply: password, public key, keyboard-interactive, an agent, and GSSAPI. The Authentication page is available when SCP or SFTP is selected.	Username and password are the normal Login dialog credentials. A TLS client certificate is a separate option for servers that require one. SSH keys do not apply.	Use an access key ID and a secret access key, or credentials discovered from the AWS environment. Those environment credentials are read again at login and are not saved into the site. This is not a username and password in the SSH or FTP sense, even though the same two boxes are reused.
Typical use	Day-to-day administration of a Linux or Unix host, website files on a host that offers SSH, and repeated synchronization when timestamps are reliable.	Legacy servers that have not been given TLS, and public file mirrors that intentionally publish anonymous access. Private business files deserve FTPS or SFTP instead.	Hosting panels and business FTP servers that stayed with FTP but added TLS. Use it when the provider says FTPS or “FTP over SSL,” not when they say SFTP.	A server that only offers the legacy copy protocol, or a specific job the administrator has tested with SCP. Prefer SFTP for new work.	Content platforms and file servers that expose a WebDAV collection, including some groupware and hosting products. It is not the default way to manage a typical Linux shell account.	Storing and retrieving objects in Amazon S3 or a compatible service such as a provider that documents an S3 API. It is the wrong choice for a Linux shell account or a classic web host’s FTP login.
Connection requirements	You need a hostname, a username, and an authentication method. The only mandatory box for opening a session is the hostname; other values are prompted if you leave them blank, except in special cases such as GSSAPI.	You need the FTP hostname, which hosting companies often distinguish from the website name, plus a username. Passive mode is the usual data-connection style for a PC behind a firewall or a router.	You need the hostname, the invocation method, and the account. Explicit and implicit are not two labels for the same socket. A certificate signed by a private authority may need to be checked and then accepted only if it matches.	A working SCP session often needs more than the hostname. The SCP/Shell page of Advanced Site Settings exists because the client drives a remote shell. The shell environment is expected to be English.	You need the WebDAV endpoint hostname and the path the provider documented. That hostname is often different from the public site. HTTPS is the variant to select unless you are on a network the administrator has called safe and no password is involved.	You need the endpoint hostname, the access key, and the bucket the key is allowed to use. Compatible services publish their own endpoint. A regional Amazon endpoint may be required instead of a generic hostname.
Common ports	22. SSH servers normally listen on port 22, and the Login dialog fills that in. Use another port only when the administrator gave you one. Port 22 does not by itself prove the service is SFTP; the server must have the SFTP subsystem enabled.	21. The usual FTP control port is 21. That port carries commands, including the password, in the clear. File data uses a separate data connection. Do not confuse port 21 with port 22.	21 explicit, 990 implicit. Explicit FTPS usually starts on port 21 and then negotiates TLS. Implicit FTPS usually expects TLS immediately on port 990, with a related data port of 989. The Login dialog selects 990 for implicit FTPS and 21 for explicit FTPS. The administrator must say which listener they run.	22. SCP uses the SSH port, normally 22, the same number SFTP uses. The port does not tell you which of the two protocols the server will allow. The File protocol selection does.	443 or 80. WebDAV over HTTPS uses port 443. Plain WebDAV over HTTP uses port 80. The secure choice is the one to use whenever the server offers it. A website that loads in a browser is not automatically a WebDAV endpoint.	443. Amazon S3 and typical compatible services use HTTPS on port 443. This is an API endpoint, not an FTP or SSH port. The unsecured variant in the Login dialog is only meaningful for a third-party service that actually allows it. Amazon S3 does not support an unsecured connection.
Compatibility	SFTP is widely supported by SSH servers, but it is a different protocol from FTP and from FTPS. An FTP-only host will refuse it. Some SSH servers allow a shell or SCP and still have the SFTP subsystem turned off.	An FTP client cannot log in to an SFTP port, and an SFTP client cannot log in to a plain FTP port. The server software is different even when a host offers both on different ports.	Plain FTP clients can sometimes still use an explicit server if that server allows an unencrypted fallback. This client does not leave the channels unencrypted once FTPS is selected. An implicit server usually drops clients that do not speak TLS immediately.	SCP is associated with OpenSSH and similar servers. It is not FTP. Selecting SCP against an FTP host will fail even if the firewall is open.	Support varies widely. Some servers implement locking, properties, or timestamps poorly. A generic web server without the WebDAV methods enabled will not accept the session.	S3 is an object API. Buckets hold objects. What looks like a folder is a key prefix. Tools that expect FTP commands, SSH, or Unix permissions will not apply.
Practical limitations	Many small files can feel slow because each operation waits for confirmation, and encryption adds work. Recursive permission changes run file by file. Resume in this client requires SFTP version 2 or newer, which added the rename command the client uses.	Transfer setup for a large batch of small files can be slow even though each file’s data path is simple. Listings and timestamps depend on the server. MLSD is the preferred listing command when the server supports it; older LIST behavior leaves the time zone undefined. Resume is supported by the protocol.	FTPS is still FTP, so firewalls and data connections remain part of the setup. It does not gain SSH features such as public-key login or a shell. Resume remains an FTP capability, unlike WebDAV or SCP in this client.	This client cannot resume an SCP transfer. Canceling a transfer means ending the session. Directory listings depend on shell commands, so environment variables and daylight-saving behavior can change names and timestamps. Those timestamp differences cause trouble when comparing directories.	This client does not support transfer resume over WebDAV. Text transfer mode is not supported. Few servers allow the client to set timestamps. Do not expect Unix permission bits.	There is no true remote shell and no Unix permission dialog that the bucket will honor. Versioning, storage class, and server-side encryption are properties of the storage service. Not every compatible provider implements every Amazon feature.
In the Windows client	SFTP is the usual protocol to select, and the product’s default mode is SFTP with SCP as a fallback. Choose SFTP explicitly when you know the server supports it.	In the Login dialog, FTP is its own file protocol. Encryption choices on that protocol switch the session to FTPS. They do not turn FTP into SFTP.	Session URLs use ftpes for explicit TLS and ftps for implicit TLS. Those scheme names appear in scripting, not as a reason to bypass the certificate check.	SCP remains available, and the product can fall back from SFTP to SCP. Treat that as a compatibility path, not as the protocol to standardize on.	HTTP and HTTPS session URLs are treated as WebDAV, except hostnames the application recognizes as S3 endpoints, which it treats as S3.	The application uses the S3 REST interface and can also connect to compatible storage when you use that service’s endpoint and credentials. URLs on known S3 hostnames are recognized as S3 rather than WebDAV.

Uncheck a protocol to hide its column. At least two stay visible. The full table is in the page, so the facts remain available if you print it.

Winsaip is an independent educational resource and is not affiliated with or endorsed by the developers of WinSCP.