Hey all, I keep seeing FileZilla mentioned every time someone talks about uploading a website to a host. What exactly is the FileZilla client, how does it work under the hood, and is it actually worth using? Also curious about any downsides before I install it
FileZilla Client is a free, open-source, cross-platform file transfer program. It lets you move files between your own computer and a remote server. It supports FTP, SFTP, and FTPS (which is FTP running over SSL/TLS for encryption). It runs on Windows, Linux, and macOS, so it doesn’t matter what system you’re on.
How it works is pretty simple once you see it. You open the program and you get two panels side by side. The left panel shows the files on your own computer, and the right panel shows the files on the server once you connect. You just drag and drop files between the two sides, or right click to upload and download. There’s also a site manager where you can save your server logins so you don’t have to type them in every time, and a transfer queue at the bottom that shows what’s currently moving and what’s still waiting.
If you’re not sure about the difference between the client and the server side of things, there’s an old thread on the official forum that explains it well. Basically the client is what you use to connect out to a server, and the server software is a separate thing entirely that you’d only need if you wanted to host your own FTP server.
On that cloud storage point, if you mainly work with things like Google Drive or Dropbox and want them to behave like a normal folder on your Mac, something like CloudMounter is worth knowing about. It mounts cloud storage as a local drive so you can just drag files in and out of it in Finder, without needing FileZilla Pro or dealing with FTP settings at all. Different tool for a different job, but it fills the exact gap that free FileZilla has.
Overall FileZilla client is a solid pick if you just need reliable FTP or SFTP access to a server. Just don’t expect built in cloud support unless you pay for the Pro version.
9 Likes
Use SFTP rather than plain FTP whenever your hosting provider supports it, since FTP sends credentials without encryption. FileZilla handles the transfer, but you still need the correct host, port, username, password or SSH key, and remote folder from your provider.
If your host has a browser-based file manager or a proper deployment workflow, you may not need FileZilla at all. It is useful, but it is only a file-transfer client. It does not build your site, configure the server, create databases, or safely deploy code for you.
Under the hood, FileZilla opens a connection to the server using FTP, FTPS, or SFTP, authenticates you, requests directory listings, and sends commands to upload, download, rename, delete, or change file permissions. The two-panel interface makes those operations look like ordinary file management. When you drag a folder across, it breaks that action into a queue of individual transfers and reports failures, retries, and conflicts.
The practical catch is that drag-and-drop access can make destructive mistakes very easy. Uploading an old copy can overwrite newer server files, and deleting from the remote panel affects the actual hosted site. FileZilla is not version control, a backup system, or a true folder-sync tool. Before changing a live site, confirm the remote path, keep a backup, and be cautious with overwrite prompts. It is surprisingly common to connect successfully and upload everything into the wrong directory because the account opens above the real web root.
@xlogiccachex is right about choosing SFTP when it is available. Saved credentials deserve some thought too, especially on a shared computer. SSH keys are generally preferable to repeatedly entering or storing a server password, assuming the host supports them.
For a small static site or occasional WordPress file repair, FileZilla is worth using because it gives you direct access and makes failed transfers visible. For regular application releases, Git-based deployment, a hosting control panel, or an automated deployment process is usually safer and more repeatable. CloudMounter belongs more on the cloud-storage side of the discussion. It can be convenient when your files live in services such as Google Drive or Dropbox, but mounting storage as a drive does not replace SFTP access to a web server unless that server is exposed through a compatible service.
So I would treat FileZilla as a dependable manual transfer tool, not as the default answer for every website. It is excellent when you need to put known files in a known server directory. It becomes less attractive when several people edit the same site or when you need reliable rollbacks, synchronization, and repeatable releases.
If you expect to update a live site regularly, the answer changes. FileZilla is much easier to learn than command-line tools, but it is less controlled than deploying through Git, rsync, or a hosting platform. For occasional uploads, that simplicity is the main attraction. You connect, find the web directory, and move files. There is very little setup beyond getting the correct credentials from your host.
It helps to compare FileZilla with a normal file manager. The remote panel may look like another disk, but it is not continuously mounted or synchronized. FileZilla asks the server for a directory listing, then converts each action you take into protocol commands. Dropping twenty files into a folder produces twenty separate transfer jobs. If one fails, the queue records it so you can retry rather than guessing what completed.
Compared with Git, FileZilla does not understand projects, revisions, or dependencies. Compared with rsync, it generally has less intelligence about transferring only what changed. Compared with a browser-based hosting file manager, it is usually better for moving many files and folders at once. That puts it in a useful middle ground: more capable than clicking around in a control panel, but nowhere near a release system.
A small annoyance people run into is connection limits. FileZilla can transfer several files in parallel, while some cheap hosting accounts allow only a small number of simultaneous connections. The result can be “too many connections” errors even though the login details are correct. Reducing the concurrent transfer count usually fixes that. Lots of tiny files can still take longer than expected because each file involves separate server operations.
So yes, it is worth using when the job is manual file transfer and you want a clear view of both sides. I agree with @xzenshellx that it should not be mistaken for deployment or synchronization. FileZilla is best viewed as a remote file manager with a transfer queue. Once your website updates need testing, coordination, and reliable rollbacks, its convenience starts becoming a liability.
If your host does not provide FTP or SFTP access, installing FileZilla will not help. That confused me at first because it sounds like FileZilla somehow finds your website from its domain name. It actually needs a server address, username, authentication details, port, and usually the correct web folder from the hosting company.
Once connected, it is basically a remote file browser. The left side is your computer and the right side is the hosting server. Dragging a file across tells FileZilla to transfer its contents using the chosen protocol. It does not understand that index.html is a homepage or that a folder belongs to WordPress. It just moves, renames, and deletes files where you tell it to.
A detail that can make beginners think the upload failed is caching. The file may have transferred correctly while the browser, hosting cache, or CDN still serves the older version. Check FileZilla’s successful and failed transfer tabs, confirm the remote file’s timestamp and size, then clear the relevant cache before uploading the same file repeatedly.
I agree with the warnings about SFTP and accidental overwrites. For occasional manual changes, FileZilla is worth using because the queue makes transfers easier to inspect than a basic browser file manager. For frequent site updates, though, it starts to feel risky because it cannot tell whether your local copy is newer, complete, or safe to publish.
Don’t save your server passwords in FileZilla without setting a master password first. For years the thing stored saved logins in plain text on disk, and unless you turn on the master password option it can still hand them over to anything poking around your user folder. @xzenshellx touched on saved credentials on shared machines, but this isn’t just a shared-computer problem. Malware that scrapes FileZilla’s config files has been a thing for a long time. If you connect a lot, SSH keys really are the cleaner route, like the earlier replies said.
Past that, most of the thread is solid and I don’t have much to argue with. The two-panel remote-file-manager description is accurate. Where I’d shift the emphasis a bit: people treat the ‘wrong directory’ mistake as user error, but half the time it’s the host’s fault for dumping you above the web root with a pile of folders that all look plausible. public_html, www, htdocs, httpdocs, and sometimes a domain-named folder sitting next to them. First thing to do after connecting is upload a tiny test file and see if it shows up at your URL before you move anything real. Cheap insurance and it takes ten seconds.
On the connection limit thing @bytefalcon3221 mentioned, yeah, dropping the concurrent transfers to one or two clears up most of the ‘too many connections’ noise on budget shared hosting. The other half of slow transfers with lots of small files is just protocol overhead, and no setting fixes that. SFTP in particular can crawl on thousands of tiny files because each one is its own round trip. If you’re pushing a big framework with a huge node_modules folder or similar, zip it, upload the one archive, and unzip it server-side through your control panel or SSH. Way faster than watching 8,000 files trickle across.
CloudMounter got brought up a couple times and I’d keep it in its lane. It’s genuinely handy if your actual files live in Dropbox or Drive and you want them in Finder like a normal drive. But it’s answering a different question than ‘how do I get my site onto my host.’ Unless your web space is exposed through something it can mount, it doesn’t replace the SFTP workflow at all. Useful tool, wrong shelf for most of this discussion.
Short version of my opinion: FileZilla is fine and I’d still reach for it for a one-off fix or a static site. The moment you’re editing the same live site more than occasionally, the lack of any ‘is my local copy actually newer’ awareness turns it into a foot-gun, and that’s when rsync or a git deploy stops being overkill and starts being the sane choice.
Don’t treat FileZilla’s “successful transfer” message as proof your site is working. It only confirms the file reached the server, not that you chose the right directory, permissions, filename case, or configuration. FileZilla is worth keeping for occasional SFTP work, but calling it a website deployment tool gives it far more credit than it deserves.
Half the ‘which copy is newer’ confusion goes away if you just turn on preserve timestamps in FileZilla, and almost nobody does. Out of the box it stamps uploaded files with the upload time, not the original modified time. So when you go back later and try to eyeball whether your local file or the server file is fresher, the timestamps lie to you. There’s a setting for it under transfer options. Flip it on once and forget about it. Doesn’t turn FileZilla into rsync, but it removes one dumb source of doubt that people in this thread keep pointing at.
The other thing nobody flagged is the transfer type setting. FileZilla defaults to auto, where it decides binary or ASCII based on file extension. Ninety-nine percent of the time that’s fine, but auto ASCII mode rewrites line endings, and if it ever misjudges a file you can get subtle corruption that a ‘successful transfer’ message will happily report as done. @binaryninja2540 is right that the green success tick only means bytes arrived. It doesn’t mean the bytes are the same bytes. If you’re paranoid, force binary and stop letting it guess.
@wolf.tech’s test file trick is the best single tip in here. Upload one throwaway file, load it in the browser, confirm you’re actually in the web root before you touch anything real. That ten seconds saves you from the classic dump-everything-one-level-too-high mistake, which really is half the host’s fault for the folder soup they hand you.
On CloudMounter, it’s come up a few times and I’d leave it where the earlier replies put it. Genuinely handy if your files live in Drive or Dropbox and you want them in Finder like a normal drive. But that’s a storage convenience, not a way onto your web host. Different problem, and mounting a cloud drive won’t give you the server-side control you need for a live site unless the host happens to expose something compatible.
My take: FileZilla is a screwdriver, not a workshop. Great for a known file into a known folder. The second you’re publishing changes to a site people actually visit, on any kind of schedule, the lack of change awareness stops being a quirk and starts being how you overwrite something important at 11pm. Manual fixes, yes. Ongoing releases, no.