Taking FileZilla off a Mac for good

A FileZilla uninstall on a Mac is not the hard part. Dragging the app to the Trash takes a few seconds and nothing breaks. The part worth slowing down for is what does not go with it: the site list, the stored credentials, the transfer queue and the cached host keys, all of which sit in the home folder and survive the app by design. Anyone searching for how to uninstall FileZilla is usually about to hand the machine to someone else, or is switching to another transfer tool, or has hit a bug and wants a clean slate. Those three cases need different amounts of care, and only one of them is satisfied by deleting the application.

What follows separates the removal from the cleanup, names what is actually left behind, and covers the question that should be settled before any of it happens: whether the credentials that FileZilla was holding need to be changed rather than merely deleted.

What a FileZilla install on a Mac actually consists of

FileZilla for macOS is not distributed as an installer package. The official download page offers the client as an archive containing an application bundle, listed at the time of writing as FileZilla_3.71.1_macos-arm64.app.tar.bz2 for Apple Silicon and FileZilla_3.71.1_macos-x86.app.tar.bz2 for Intel, with a stated requirement of macOS 10.13.2 or newer.

That single detail decides the entire removal procedure. An archive containing an app bundle cannot write files outside itself during installation, because there is no installation step. There is no package receipt in the system database, no privileged helper tool, no launch daemon set to run at login, and no system extension asking for approval in System Settings. Whatever ends up outside the bundle is written later, by the running application, into the user's own home folder.

This is worth stating plainly because a large number of uninstall guides for Mac software are written against a different model, the one where an installer scatters components across the system and a dedicated uninstaller is needed to find them again. FileZilla on macOS does not work that way. No third party cleaner is required and none of the usual system directories need to be touched.

Component	Where it comes from	Removed by trashing the app
The application bundle	The downloaded archive	Yes
Site list and saved logins	Written by the app on first use	No
Interface settings and layout	Written by the app	No
Transfer queue and history	Written by the app	No
Known host key fingerprints	Written on first SFTP connect	No
Package receipts, daemons, extensions	Not created at all	Nothing to remove

The part that takes twenty seconds

Quit FileZilla first. Transfers in progress write to the queue as they go, and quitting mid transfer leaves a half finished file on the remote server that is easy to forget about. Check the queue pane, let anything active finish or cancel it deliberately, then quit from the menu rather than force quitting.

Then drag FileZilla.app from the Applications folder to the Trash and empty it. That is the whole removal of the software itself. If the app was launched from the Downloads folder rather than moved to Applications, which is common with archive based distributions, it will be sitting wherever the archive was expanded, so it is worth searching the whole home folder rather than assuming the standard location.

Nothing else on the system depends on the bundle. Any alias in the Dock will show a question mark and can be dragged off. File associations that pointed at FileZilla fall back to the next available handler without intervention.

The part people miss: the settings folder

Everything FileZilla remembers about servers is stored outside the application bundle, in plain files under the user's home folder. Deleting the app leaves all of it in place. For someone reinstalling later this is a feature, since the site list comes straight back. For someone handing the Mac to a colleague, selling it, or trying to reproduce a bug from a clean state, it is the whole problem.

Rather than trusting a path copied from a forum post, find the files on the machine in question:

find ~ -maxdepth 5 -iname "*filezilla*" -not -path "*/Trash/*" 2>/dev/null

Run that before deleting anything. It reports the configuration directory, any leftover archives in Downloads, and any exported site list files that were saved somewhere and forgotten. Look at the list and decide file by file. The configuration directory typically holds separate XML files for the site list, the general settings, the recently visited servers and the queue, plus a database file for transfer history. The names are readable enough that opening one in a text editor makes its purpose obvious.

Two items on that list deserve individual attention. The first is the site list, because of what it contains. The second is any file with an .xml extension sitting outside the configuration directory, which is almost always an export made by someone who wanted to move their sites to another machine and never deleted the copy.

Saved passwords are a separate decision from deleted passwords

FileZilla connects over FTP, FTP over TLS and SFTP. When a site is saved with its login, the credential has to be recoverable by the app at connect time, which means it is stored on disk in a form the app can read back without asking anyone. Deleting that file removes the local copy. It does not change the password on the server, and it does not undo the fact that the credential existed in a readable file for as long as the app was installed.

The distinction matters in three situations, and in all three the answer is to rotate rather than simply delete:

• The Mac has been shared, synced to a backup service, or is being passed on. A Time Machine snapshot or a cloud backup taken while FileZilla was installed contains the site list as it was on that day, and deleting the live copy does nothing to the backups.
• Any of the saved sites used plain FTP. Plain FTP sends the username and password across the network unencrypted, which is a property of the protocol and not a flaw in any particular client. If those credentials have been in use over plain FTP for a long time, uninstalling is a natural moment to retire them.
• The same password was reused for the hosting control panel or a database. Web hosting accounts frequently issue one credential that works for several services, so an FTP login is often not only an FTP login.

Practically: open the site list one last time before removing it, write down which servers appear, then change those passwords at the host. Ten minutes of work that turns a cleanup into an actual security improvement. Once that is done, the files can go.

If the plan is to move the sites to a different application rather than abandon them, copy the entire configuration directory to an external disk before deleting it. Most transfer tools can import a FileZilla site list, and having the original file available is easier than reconstructing a dozen host names from memory.

If a crash was the reason, check the version before giving up

A recurring pattern in uninstall searches is that nothing is wrong with the choice of tool. Something broke after a macOS update, and removing the app looks like the fastest route to a working machine.

The project's published changelog is specific about one case that hit Mac users recently. Revision 11555, dated 26 August 2026 and released as version 3.71.1, is described as a work around for a bug in macOS 27 where setting the locale to a language other than English triggers crashes in AppKit. Anyone running FileZilla on the current macOS with the interface set to a non-English language, and seeing it fall over, was hitting a system level problem rather than a broken install. The fix ships in the current version.

That is the general rule worth applying before any uninstall done in frustration. Note the exact version in use, look at what changed since it was published, and check whether the symptom is already named there. The FileZilla project publishes its commit log publicly with dates, so the check takes a couple of minutes. Reinstalling the same old version after a clean removal reproduces the same crash, and the time spent cleaning up is wasted.

What takes over the job

Removing the tool leaves a gap, and the gap is narrower than it looks. Sorting the replacement by what is actually needed avoids installing something larger than the task.

Need	Option available	Cost
Occasional read only browsing of an FTP server	Finder, using Go then Connect to Server	Included with macOS
Scripted or repeated transfers over SSH	scp and rsync in Terminal	Included with macOS
Cloud storage services alongside FTP and SFTP	FileZilla Pro	From 12,99 € for a single device, macOS only
The same across Mac, Windows and Linux	FileZilla Pro, multiple devices	From 29,99 €
Remote storage mounted into Finder	FileZilla Pro RemoteDrive	12,99 € per year, macOS only
Local file work with a shell in the same window	A file manager with a built in terminal	Varies

One caveat on the first row. The FTP support built into macOS mounts a remote directory read only. The system manual page for the FTP mount command states that the read only option is applied whether or not it was requested, because the implementation does not allow files to be opened for writing on the server. It is fine for looking at what is on a server. It cannot replace an upload tool.

The last row is the one most people in this situation actually land on, because the original reason for opening a transfer client is often not transfer at all. It is that a folder needs sorting, renaming or comparing before anything is sent anywhere, and the local side of that work happens in a file window. Doing the sorting, the shell commands and the transfer in one window removes a context switch that a dedicated FTP client cannot remove on its own. The comparison of file managers sets out where the categories overlap and where they do not.

What to change first

Rotate the passwords for any server that was saved in the site list, then delete the configuration directory, then trash the app. That order matters, because once the site list is gone the record of which credentials need changing is gone with it. If the uninstall was triggered by a crash rather than a decision, check the current version first, since the fix may already be published.

For the local half of the work, sorting and renaming and running commands against the same folder, a window that holds the files and a shell together removes most of the round trips. The features list shows what that looks like in practice, and Atriens is one option in that category.