FTP client for Mac: what macOS still does on its own

The search for an FTP client on a Mac usually starts after something failed rather than before something began. A host sends credentials, the obvious first attempt is Finder or the terminal, and one of the two behaves in a way that makes no sense: the terminal reports that the command does not exist, or the server mounts in Finder and then refuses every upload. Both behaviours are documented, both are deliberate, and understanding them decides whether a third party client is needed at all or whether the right answer is a different protocol entirely.

What the system includes, and what it stopped including

Current macOS releases do not ship a command line ftp client. Typing which ftp in a shell returns nothing at all. The telnet command went the same way in the same era, and anything installed under those names today arrived through Homebrew or MacPorts rather than from Apple.

What did stay is more capable than what left. OpenSSH is present, which means sftp and scp are both at /usr/bin and ready to use with no installation at all. The bundled curl is also present, and running curl --version prints a protocol line that is worth reading once, because it explains a dead end that catches people out regularly. The list names dict, file, ftp, ftps, gopher, http, https, imap, ldap, mqtt, pop3, rtsp, smb, smtp, telnet and tftp.

What is not on that line matters more than what is. There is no sftp and no scp, because the version Apple ships was compiled without SSH support. So the shell that cannot do plain FTP interactively can still do it through curl, while the tool most people reach for to do SFTP cannot, and the tool that can do SFTP is a different binary entirely. The split catches out anyone who assumes one command covers everything with an F in the name.

Finally, /sbin/mount_ftp is still installed. That is the piece Finder uses, and it is where the upload problem comes from.

Finder can mount an FTP server, and the mount is read only

Connect to Server in Finder, reachable with Command-K, accepts an ftp:// address and mounts the remote directory as a volume. Files can be dragged off it. Files cannot be dragged onto it, and the failure is not a permissions misconfiguration on the server. It is enforced locally, before the server is ever consulted.

The manual page for the mount helper states the rule directly. The read only flag is applied whether or not it was requested, because the helper does not permit files to be opened for writing on remote servers. Port 21 is assumed when the address does not name one.

Apple's own documentation says the same thing from the user side.

With read-only access, you can copy files from the server, but to copy files to the server, you may need another FTP app. Source: support.apple.com

The same page carries a second signal that is easy to miss. Its table of address formats gives explicit examples for SMB, NFS and WebDAV, and no example row for FTP at all. The capability is documented as present and simultaneously not given the same standing as the others. Treating Finder as a viewer for FTP servers and nothing more matches how the system actually behaves.

Three protocols, one word

The word FTP is used for at least three arrangements that share almost nothing beyond a purpose.

FTP is the original protocol. The username, the password, and the file contents all cross the network unencrypted. It opens a control connection, typically on port 21, and then negotiates separate connections for each transfer, which is why it interacts badly with firewalls and needs a passive mode setting that has confused people for decades.

FTPS is FTP with TLS wrapped around it. It comes in an explicit form, where the client connects normally and then asks to upgrade, and an implicit form, where the connection is encrypted from the first byte on a separate port. A client that supports one does not automatically support the other, and hosts rarely say which they mean.

SFTP is not FTP at all. It is a subsystem of SSH, runs over the SSH port, and authenticates the same way an SSH login does, including with keys instead of passwords. Nothing in it is inherited from FTP except the letters.

	Transport	Usual port	Credentials in transit	Ships with macOS
FTP	Plain TCP	21	Readable	Through curl only
FTPS	TLS	21 or 990	Encrypted	Through curl only
SFTP	SSH	22	Encrypted	Yes, as sftp

The practical consequence is that the answer to "which FTP client" often turns out to be "not an FTP client". If the host offers SSH access, sftp is already installed, already encrypted, and already able to use a key pair. Reaching for a downloaded client before checking that is a common way to add software to solve a problem that has no software left to solve.

Find out what the server actually offers before choosing

Hosting control panels label things loosely, and the label on the credentials email is not evidence. Three checks settle it in about a minute.

Try SSH first, because it decides everything else. If ssh user@host connects, then sftp user@host will too, and the decision is made. If it refuses, note whether the refusal is a connection failure or an authentication failure, because those mean different things: the first suggests SSH is not offered, the second suggests it is offered and the credentials are for something else.

Then test plain FTP with the tool already installed. Running curl -v ftp://host/ shows the server greeting, the authentication exchange, and any TLS negotiation, all in a form that can be pasted into a support ticket. It is a better first diagnostic than any graphical client, because a graphical client collapses every one of those steps into a single unexplained error.

Finally, ask the host one specific question rather than a general one. Not "do you support FTP", which will always get a yes, but "does the account allow SFTP over SSH, and if not, is the FTPS mode explicit or implicit". The answer determines which clients can connect at all.

Shared hosting adds one more variable worth settling in the same message. Some plans expose SSH only after it is switched on in a control panel, some restrict it to an allow list of addresses, and some issue a separate username for it that does not match the FTP one. A refusal to connect is therefore weak evidence on its own, and the same account can go from unusable to working without any change to the client.

Where the clients actually differ

Once the protocol is settled, client choice is narrower than the number of options suggests. Almost all of them speak FTP, FTPS and SFTP. The differences are in licensing, in what happens to a transfer that fails halfway, and in whether the app is only a transfer tool or also a file manager.

Client	Cost	Licence shape
Cyberduck	Free from the project site	Open source, donation supported. A donation of at least 10 USD returns a key that turns off the donation prompt
Cyberduck via the App Store	23.99 USD, 4,000 JPY	The same app, sold as a paid download
FileZilla	Free	Open source
Commander One	Free base app, 29.99 USD for the PRO Pack on a single Mac	The PRO features can be trialled for 15 days
ForkLift 4	19.95 USD single user with one year of updates, 34.95 USD with two years	Perpetual use of the version covered, updates only within the period
Transmit 5	45 USD after a 7 day trial	One time purchase, requires macOS 13.0 or later

Two rows in that table are the same software. Cyberduck downloaded from the project site is free and asks for a donation; the App Store listing for the identical app is a paid purchase. Neither route is a trap. It is a reminder that "free" describes a distribution channel rather than a piece of software, and that the answer changes depending on where the download button was.

The licence shapes differ in a way that matters more than the numbers. A one time purchase keeps working after the vendor stops shipping updates. A licence with an update window keeps working too, but new versions stop arriving at a date set when the licence was bought. An open source project has no expiry at all and no obligation to keep going either. None of these is better in the abstract, and the right one depends entirely on how long the setup is expected to stay untouched.

The parts a client does not solve

A downloaded client fixes the upload problem and leaves several others in place.

Interrupted transfers. Any large upload over a connection that drops needs resume, and the behaviour differs per protocol and per client. On the SFTP side this is built into the tools already installed: sftp -a continues an interrupted transfer instead of starting over, and inside an interactive session the reget and reput commands do the same for a single file. The warning in the manual page is worth respecting, because a resumed file whose partial contents differ from the source is likely to end up corrupt rather than merely incomplete.

Directory trees and links. Recursive transfer with sftp -r copies whole directories but does not follow symbolic links during the traversal. On a Mac where parts of a project tree are symlinked to somewhere else, that produces an upload that looks complete and is not.

What the files look like on arrival. Ownership, group and permission bits are set by the receiving system, not by the sending one. A deploy that works locally and fails on the server is frequently a permissions difference introduced at the moment of transfer rather than a fault in the files.

The window count. Even with the right client installed, the working shape is often three windows: a folder view to find the files, a transfer client to move them, and a terminal to check the result on the far side. The transfer stops being the slow part and the switching becomes it. Handling both in one place is the argument for a file manager with a built in terminal rather than for a dedicated transfer app, and the trade offs between the two shapes are laid out in the comparison with other file managers.

What to change first

Before installing anything, run ssh user@host once. If it connects, the client question is answered: sftp is already on the machine, already encrypted, and already able to use keys. If it does not, run curl -v ftp://host/ and take the output to the host rather than guessing at settings. Only after those two results is it worth comparing clients, and the shortlist that survives is usually two entries long. If the remaining friction is the number of windows rather than the transfer itself, Atriens is built for that case.