File transfer speed is very low. WinSCP does not utilize all available bandwidth. How do I improve the transfer speed?

When using SSH or TLS/SSL, file transfers in WinSCP are encrypted and encryption is CPU intensive. Either your local machine or your server might not be able to encrypt file transfer stream at the same speed, your connection is able to transfer it.

WinSCP as well as most (if not all) SFTP servers cannot distribute the encryption/decryption among CPU cores, so it’s actually a capacity of a single CPU core that limits the transfer speed.

Use the Windows Task manager to see, if one of the cores is utilized to its maximum during the transfer.

In case the speed is throttled by CPU, it may help if you choose different encryption algorithm on SSH page of Advanced Site Settings dialog (supposing you are using SSH-based file transfer protocol, such as SFTP or SCP). Blowfish is usually a lot faster than AES. It may also help, if you turn off compression, if you have turned it on before.

Network delay/latency affects particularly SFTP, as it is a packet oriented-protocol. When transferring, the SFTP client (WinSCP) sends a read/write request to the SFTP server, waits for a response; and repeats, until the end of the file.

Even if your connection is fast, if the server is far away (or slow), it takes a time for the response to arrive back. If the client spends this time uselessly waiting, your transfer speed will be low.

Most SFTP clients (including WinSCP) overcome the problem by both requesting/sending a large chunk of the file in each single read/write request and by sending (queuing) multiple requests without waiting for a response to previous. For example WinSCP can request up to 32 chunks for 32 KB each at once, totaling 1 MB (these are defaults which can be altered with SFTPDownloadQueue and SFTPUploadQueue raw session settings). But if there’s a big discrepancy between the bandwidth and the network delay, even that 1 MB can be too small to saturate the bandwidth.

See also Bandwidth-delay product on Wikipedia.

In case the speed is throttled by a connection latency, it may help if you use SCP protocol instead of SFTP. SCP is less affected by the latency. Though we got reports of exactly opposite behavior too (SFTP being faster than SCP). When connection latency is the bottleneck, it may additionally help if you turn on compression (though that will have small effect if you are transferring large media files, which are compressed already). Toggling Optimize connection buffer size, in either way, can help too.

An underlying TCP protocol can suffer a similar problem too. In which case it will affect all other protocols, including SCP, FTP, WebDAV or S3.

Also there’s a lots to improve in performance of WinSCP itself 164. So it may get better in future versions.

Also note that as SSH code of WinSCP is based on PuTTY, file transfers with SSH-based protocols can hardly be faster than PuTTY (PSCP/PSFTP) is. Hence there is no point asking for speed improvements, if you get the same rate with PuTTY.

If WinSCP started being slow suddenly, check if you did not enable logging on “Debug” level inadvertently.

When comparing batch file transfer speed of WinSCP, note that it by default transfers all files sequentially using a single connection. While some other clients use multiple connection by default. If you prefer, you can transfer files using multiple parallel connections in WinSCP too.