Replacing FileZilla without losing the shortcuts you rely on

Most people looking for a FileZilla alternative are not unhappy with FileZilla. They have hit one specific edge: a cloud bucket the free client will not open, a queue that crawls on a fibre line, an interface that has not changed shape in a decade, or a Mac that now runs on Apple Silicon while the download page still hands over an Intel binary. The tool is fine. One part of the job has moved past it.

That distinction matters, because the four edges point at four different replacements. Swapping a whole workflow to solve one of them costs a week of muscle memory and usually solves nothing. Worth naming the edge first.

Three different problems hide behind one search

The first problem is protocol coverage. The free FileZilla client speaks FTP, FTP over SSL/TLS, and SSH File Transfer Protocol. Object storage and consumer cloud drives are not in that list. Anyone who needs to push a build to an S3 bucket or pull a client folder out of Google Drive is not looking for a better transfer client. They are looking for one that speaks more protocols.

The second problem is throughput. Transfers that used to saturate the line now take an afternoon. The causes here are almost never the application: a per site connection limit, an enabled speed cap left over from a hotel network, an Intel build running under translation, a server that only tolerates one data channel at a time. A different client can mask this. It rarely fixes it.

The third problem is shape. FileZilla is a transfer client with a local pane attached. It was never designed to be the place where local work happens. People who spend their day moving, renaming and inspecting files on their own disk keep bouncing between three windows: the Finder for local work, FileZilla for the remote side, and a terminal for anything either one cannot do. That is not a transfer problem. That is a file manager problem, and the answer sits in a different category of application entirely.

A fourth edge is worth separating out because it looks like a bug and is actually a packaging decision. It is covered further down.

What the free FileZilla client actually covers

Before shopping, it is worth being exact about what would be given up. The published feature list is longer than most users realise, and several items on it are the reason switching hurts.

Supports FTP, FTP over SSL/TLS (FTPS) and SSH File Transfer Protocol (SFTP) Source: filezilla-project.org

The same page lists a tabbed interface, a site manager with bookmarks, a persistent transfer queue with resume for files over 4GB, configurable speed limits, filename filters, directory comparison, synchronised directory browsing, remote file search, and remote file editing. Add IPv6, proxy support for HTTP/1.1, SOCKS5 and FTP proxies, and logging to file.

Two of those deserve attention when comparing. Synchronised directory browsing keeps the local and remote panes walking the same tree, which is the single fastest way to work on a site with a deep structure. Directory comparison highlights what differs between the two sides before anything is transferred. Plenty of paid clients have both. Plenty of free ones have neither, and their absence is usually discovered on day three of a trial.

The current stable release is 3.71.1, published on 26 August 2026, and the project moved to the GPL version 3 or later with release 3.70.0 in April 2026. Development is active, with eleven releases inside the last six months. Whatever the reason for looking elsewhere, an abandoned project is not it.

The upgrade path inside FileZilla itself

The protocol gap has an official answer that does not involve leaving. FileZilla Pro adds cloud storage to the same interface: Amazon S3, Backblaze B2, Box, Dropbox, Google Cloud, Google Drive, Microsoft Azure, OneDrive, OneDrive for Business, SharePoint, OpenStack Swift and WebDAV.

The vendor is direct about where the line falls.

If your transfers are FTP/SFTP only, the free client is sufficient. Source: filezillapro.com

Pricing on the macOS tab lists a single device licence starting at 12,99 € and a multiple device licence covering up to three machines starting at 29,99 €. A separate product, FileZilla Pro RemoteDrive, mounts remote servers and cloud storage into the Finder as a yearly subscription at 12,99 €, sold through the App Store and available for macOS only.

Two details are easy to miss before buying. Trials exist only through the App Store or the Microsoft Store as a seven day run, backed by a 30 day money back guarantee on direct purchases. And the licence terms describe a perpetual licence whose activation still governs access to online services, new versions included, with the vendor advising against running an expired version because cloud provider API changes will eventually break it. Anyone budgeting this as a one time purchase should read that section twice.

The download page serves the Intel build first

Here is the packaging decision that looks like a performance bug. Open the macOS download page on any Mac and the heading reads "Download FileZilla Client for macOS (Intel)". The offered file is the x86 build, requiring macOS 10.13.2 or newer. On an Apple Silicon machine that runs through translation.

A native build does exist. It is not on that page. It appears only after following the link to additional download options, listed as a separate platform entry:

FileZilla_3.71.1_macos-arm64.app.tar.bz2 Source: filezilla-project.org

Anyone who has been updating in place since an Intel Mac is almost certainly still on the x86 binary. Checking takes ten seconds in the Activity Monitor Kind column, and switching to the arm64 build is a plain replacement. Several complaints that read as "the app got slow" resolve at exactly this step, which makes it worth trying before any alternative is downloaded.

Two related notes. The Mac distribution is a compressed archive of an application bundle, not an installer package, so the copy in the Applications folder is whatever was dragged there. And keeping two copies around produces repeated update prompts, which the official troubleshooting notes list as the cause of an application that asks to update immediately after updating.

Comparing the realistic replacements

Once the edge is named, the field narrows quickly. Every figure below comes from the vendor's own page as of today.

Option	Cost	Protocols beyond FTP family	Notable for
FileZilla, free client	Free, GPLv3 or later	None	Synchronised browsing, directory comparison, remote search
FileZilla Pro	From 12,99 € single device	S3, B2, Box, Dropbox, Google Cloud, Google Drive, Azure, OneDrive, SharePoint, Swift, WebDAV	Same interface, cloud added
Cyberduck	Free, GPL, donation funded	S3, Swift, B2, Azure, OneDrive, Google Drive, Dropbox, Box, Nextcloud, ownCloud, SMB, WebDAV	Keychain storage, Quick Look preview, Cryptomator vaults
Transmit 5	$45, trial available	S3, B2, Box, Google Drive, Azure, Dropbox, OneDrive for Business, Rackspace, DreamObjects, WebDAV	Dual pane, batch rename, open in terminal, local to local sync
File manager with built in terminal	Varies	Depends on the app	Local work and shell in one window

Cyberduck covers the widest protocol range at no cost, stores credentials in the system Keychain, and offers Quick Look previews with the space bar. Mounting remote storage as a local disk is a separate product from the same developer rather than a feature of the browser itself.

Transmit sells a one time licence with a trial and leans on a dual pane layout, batch renaming and an open in terminal command. For someone whose complaint is shape rather than protocols, that last item is the tell: it is an admission that a transfer client still has to hand off to a shell.

The bottom row is the one that gets skipped. If the daily pain is three windows rather than one missing protocol, a better transfer client does not touch it.

Recent behaviour changes worth knowing about

Some of the searches for a replacement start the day after an update, when a site that connected for years suddenly does not. The published release notes explain more of these than a support forum will, and reading them changes the decision, because a deliberate change is not a defect to escape.

Release 3.70.6 in June 2026 removed the automatic detection of FTP server type that governs remote path syntax. Unusual server types now have to be set by hand on the advanced page of the site manager. Anything that connected only because the client guessed correctly will fail until that box is filled in.

Release 3.71.0 tightened path handling further on servers configured as DOS type, rejecting malformed paths early instead of accepting them and confusing the engine. Correct behaviour, and also a change that turns a working connection into an error message on a badly configured host.

Release 3.70.0 made the replacement of invalid characters in downloaded filenames permanent, removing the option to switch it off. Anyone whose build process depended on exact filenames coming down untouched needs to know that.

One more matters for throughput specifically:

*nix, macOS: Remove custom send buffer option, rely on operating system auto-tuning Source: filezilla-project.org

That option was the standard advice for years whenever uploads underperformed on a Mac. It is gone as of the 3.70 series, and the tuning now belongs to the operating system. Advice found in an older thread pointing at a setting that no longer exists is a common source of wasted evenings.

The habits to audit before switching

Whatever the destination, five things carry the muscle memory, and losing any of them will make a better tool feel worse for a fortnight.

Site definitions come first. Exporting the site manager to XML before touching anything takes a minute and means the list can be rebuilt by hand if the new application cannot import it. Saved passwords generally do not travel, so a password manager should be open during the move.

Then the queue. A transfer list that survives quitting the application is not universal, and neither is resume on a part transferred large file. Anyone shipping video or database dumps should test both on day one with a deliberately cancelled transfer.

Third, comparison and synchronised browsing. Fourth, the filter rules that hide .DS_Store, node_modules and .git from every listing, which are worth writing down rather than recreating from memory. Fifth, the external editor binding, so that opening a remote file drops it into the right editor and saves back in place.

Run that list against the candidate before the licence is bought, not after. It also reveals how much of the work was never about transfer at all. Where the answer turns out to be local browsing, renaming and shell commands, the comparison page sets that class of tool against the transfer clients above, and the features list covers what collapsing the terminal into the same window removes from the round trip.

What to change first

Switch the download to the arm64 build and clear any leftover speed limit before evaluating anything else, because both are free and both produce the symptom people usually blame on the application. If the gap that remains is protocols, the paid tier of the same client is the shortest move; if it is the three window shuffle, that is a file manager question, and Atriens is built for the local side of it.