The jobs Finder still does better than FileZilla

Most comparisons of FileZilla against Finder start from the wrong assumption, which is that they are two attempts at the same job. They are not. FileZilla is a transfer client that grew a file browser on each side of its window. Finder is a local file browser that grew a thin ability to reach remote servers. The overlap is real but narrow, and the interesting question is not which one wins. It is which tasks each one quietly refuses to do, because that is what decides whether a Mac needs one, both, or something else entirely.

The version of FileZilla in play here is 3.71.1, the current stable release, which requires macOS 10.13.2 or newer and ships as separate builds for Intel and Apple Silicon. The Finder in play is the one in macOS 27. Everything below is stated against those two.

What macOS will and will not do with a remote server

Finder can reach a server. The route is Go then Connect to Server, and Apple's own documentation describes connecting either by browsing the Network location in the sidebar or by typing a network address. The protocol support behind that dialog comes from a small set of network filesystem plugins shipped with the system, covering SMB, NFS, HTTP based WebDAV and FTP.

Two facts about that list change the comparison completely.

The first is that FTP mounting is read only, and not by accident or configuration. The system manual page for the FTP mount command states that the read only option is applied even when it was not requested, because the implementation does not allow files to be opened with write access on servers. That sentence is in the manual page shipped with macOS 27. A Finder window onto an FTP server is a viewer. Files come down, nothing goes up, and no amount of permissions work on the server side changes it.

The second is that there is no SFTP support at all. The list of filesystems the system knows how to mount includes SMB, NFS, WebDAV, FTP and the local formats. There is no entry for SFTP, and no network filesystem plugin for it. This is the single largest gap, because SFTP over SSH is what most hosting providers and most servers administered in the last decade actually offer. The protocol Finder handles for writing is SMB, which is a local network protocol, not something a web host exposes.

Protocol	Finder in macOS 27	FileZilla 3.71.1
SMB	Read and write	Not supported
NFS	Read and write	Not supported
WebDAV over HTTPS	Read and write	Not supported in the free client
FTP	Read only mount	Read and write
FTP over TLS	Not available	Read and write
SFTP over SSH	Not available	Read and write

Read that table as a statement about scope rather than quality. Finder is built for the file shares on a local network, which it handles properly, with credentials in the keychain and volumes that behave like disks. FileZilla is built for the protocols a server on the internet actually speaks. Neither list is a subset of the other.

Where FileZilla is not replaceable by anything in macOS

Once a transfer is larger than a handful of files, a set of capabilities starts to matter that no file browser provides, and the published feature list for the client names most of them.

The transfer queue is the feature that justifies the whole application. A queue that survives errors, retries individually, and can be paused is the difference between a 4,000 file upload that completes and one that has to be restarted by hand. A Finder copy onto a mounted volume is a single operation. One network interruption and the state of the destination is a guess.

Resume for files above four gigabytes is in the same category. So are configurable transfer speed limits, which exist for the practical reason that saturating an upstream connection during working hours makes every other thing on the network unusable.

Three more are worth naming because they are genuinely hard to get elsewhere:

• Directory comparison, which highlights the differences between the local and remote listing rather than leaving it to be eyeballed.
• Synchronized directory browsing, where moving into a folder on one side moves into the matching folder on the other.
• Filename filters, which keep build artefacts, version control directories and system metadata files out of an upload without deleting them locally.

The filter point is worth expanding, because it is where a Finder copy causes lasting damage that a transfer client avoids. Copying a folder onto a mounted volume in Finder takes the whole folder, including the hidden metadata files the system writes to record window positions and icon arrangements, and including resource fork companions for files that carry them. On a web server those files are harmless clutter at best and publicly readable at worst, and clearing them out afterwards means connecting again and deleting by hand. A filter set once in the client keeps them out of the upload while leaving them alone locally, which is the correct division.

Credential handling is a second structural difference. Finder puts server logins in the keychain, which is encrypted and unlocked by the account password. A transfer client keeps its own site list, which is why that file matters when a machine changes hands.

Add remote file editing, logging to file, proxy support including SOCKS5, keep alive and remote file search, and the shape becomes clear. These are the tools of someone who moves a site rather than a file. Finder has no equivalent and is not attempting one.

What Finder does that FileZilla does not attempt

The reverse list is longer than transfer minded people expect, and it is the reason nobody actually uninstalls Finder.

Quick Look is the first item. Pressing the space bar on a file renders the document, the image, the video or the archive without opening an application, and the same preview engine is what draws thumbnails throughout the system. Working through a folder of two hundred screenshots to find one is a Quick Look task, and there is no version of it inside a transfer client.

Tags are the second. A colour and a label attached to a file, searchable from anywhere, that travel with the file across folders and appear in the sidebar. They are a metadata layer that lives in the filesystem rather than in any application's database.

Spotlight is the third and largest. The system maintains an index of local file contents and metadata, and Finder queries it. Searching for a phrase inside a PDF from three years ago is a different operation from listing a directory, and it is only possible because the index is being maintained continuously by the operating system.

Beyond those three: AirDrop, iCloud Drive, Time Machine restore, versions of a document, the Trash as an undo of last resort, Continuity with an iPhone or iPad, drag and drop into any running application, Quick Actions, and the Open and Save panel that every app presents and that draws its sidebar and recents from Finder's own configuration. The last one is easy to overlook when counting how much of the day is spent in Finder, because it does not look like a Finder window.

Task	Finder	FileZilla
Preview a file without opening an app	Quick Look	No
Search inside local file contents	Spotlight index	No
Tag and colour code files	Yes	No
Restore a previous version of a file	Time Machine and versions	No
Queue, pause and retry 4,000 uploads	No	Yes
Compare local and remote listings	No	Yes
Limit transfer bandwidth	No	Yes
Connect over SFTP	No	Yes

The comparison people are actually making

Very few searches for this comparison come from someone choosing between the two for the first time. Most come from someone who already has both, uses Finder all day, opens FileZilla when something has to be uploaded, and is irritated by the seam between them. The irritation is specific and it is worth naming precisely, because it is not a missing feature on either side.

The work before an upload is local work. Files get renamed to a convention, images get checked at full size, a build gets run, a folder gets compared against what is already deployed, a stray metadata file gets deleted. That happens in a Finder window, a terminal, and possibly an editor. Then the upload happens somewhere else, in a two pane window whose left side is a weaker Finder and whose right side is the server.

So the same folder gets opened in two or three applications in sequence, each with its own idea of sort order, hidden files and selection. The transfer itself is usually the fastest part. The overhead is in the handoffs.

This is why the honest answer to the comparison is that it is not a choice. Finder stays, because Quick Look, Spotlight, tags and the system panels are not optional. A transfer client stays as long as files have to reach a server over SFTP, because macOS cannot do it. What is actually worth examining is the third window, the one holding the local preparation, and whether the sorting, the renaming and the shell commands can happen in one place instead of three. A file manager with a built in terminal is aimed at exactly that seam, and the comparison of file managers lays out which parts of Finder such a tool replaces and which it deliberately leaves alone.

Choosing by the actual task

A short decision list, in the order the questions come up:

• Files need to reach a web host. The server almost certainly speaks SFTP, which macOS cannot mount, so a transfer client is required. FileZilla does this for free.
• Files need to reach a shared drive on the office network. That is SMB, which Finder handles properly with keychain stored credentials and a mounted volume. No extra software.
• Cloud storage services need to appear alongside FTP and SFTP in the same window. That is the paid tier: FileZilla Pro starts at 12,99 € for a single macOS device, or 29,99 € for a licence covering macOS, Windows and Linux.
• Remote storage should appear in Finder as a mounted drive. FileZilla Pro RemoteDrive covers that at 12,99 € per year, macOS only.
• A read only look at an old FTP server is enough. Finder alone, accepting that nothing can be written back.
• The friction is in preparing files locally rather than in sending them. Neither application is the answer, and the features list for a combined file and terminal window describes the alternative.

One footnote for anyone on the current macOS whose FileZilla has been crashing. The project's changelog records a work around, shipped in 3.71.1 on 26 August 2026, for a macOS 27 bug where setting the interface language to something other than English triggers crashes in AppKit. That is a system level problem, not a broken installation, and updating resolves it.

What to change first

Keep both. Finder is not replaceable for previewing, searching and tagging local files, and FileZilla is not replaceable for writing to a server over SFTP, which macOS cannot do at any price. The overlap between them is small enough that choosing one is not the real decision.

The part worth changing is the local step that happens before every upload. If sorting a folder, running a command against it and checking the result currently means three windows, that is the seam to close, and Atriens is built around closing it.