I downloaded FileZilla because my host told me to use it, but I’m honestly a bit lost on how the file transfer part actually works. Do I just drag stuff around? Is there a button I’m missing?
The mistake that I made at first was assuming that FileZilla somehow combined the two in one, but it does not. Instead, it allows me to work with two separate panels and move the files between them. The moment I finally realized what the program actually does, everything became as simple as a child’s drawing.
Establishing the connection and learning the interface
I begin by launching FileZilla and, in Site Manager, filling in the fields provided by the host with the connection details, such as the host address, username, password, and the connection protocol. The very last one is determined by the host as well since they offer either FTP or SFTP, with the latter being more secure. I think there is no point in guessing which one to choose, so I leave this decision to the company.
Once connected, the two-panel interface becomes apparent, with one side containing the files on my computer and the other – those on the server. This was something I took too long to realize, but it appears that everything else becomes clear as day.
Uploading means selecting a file on the left and moving it to the appropriate location on the right. I can drag it across or right-click it and choose Upload. Downloading is simply the reverse: select the server file on the right and move it to the computer side on the left. Screenshots and a more formal version of the process are available in the FileZilla wiki guide and the official FileZilla walkthrough.
The lower panel is worth watching at least until I am sure everything went well instead of assuming that it did before closing it. That is the transfer queue where FileZilla shows progress and any transfers that failed. I now leave it open for a while longer before I close it, making sure the file actually got through instead of finding out later that it did not.
FileZilla is not the right tool for other tasks
The other thing I had to get used to was the difference between accessing an FTP or SFTP server and consumer-oriented cloud accounts. FileZilla is made to access servers. It does not mount things like Google Drive, Dropbox, or OneDrive as regular drives on the computer.
If the main goal is moving files among those cloud services, a tool made for mounted cloud accounts may fit better. CloudMounter can present cloud accounts as regular drives in Finder or Explorer, allowing files to be dragged between two clouds without manually downloading them first and uploading them again. That does not really put it in competition with FileZilla, since each tool addresses a different type of connection, and that alternative is the CloudMounter app option.
For now, my conclusion is that FileZilla is simple in use once a person manages to separate local, server, and queue files in mind. I would revise this conclusion if multiple attempts to transfer data using correctly set up host information failed or if FileZilla implemented the ability to directly mount the aforementioned cloud services.
Don’t queue the folder’s contents individually if you need the structure preserved. Select the destination parent directory on the server, then upload or drag the top-level site folder from the local pane. FileZilla builds the queue automatically and keeps the subfolders intact. CloudMounter is a little more relevant than @dragon.react suggests, especially when local disk space is tight and you don’t want full cloud folders synced, but it isn’t a replacement for deploying a site over SFTP.
First decide whether the server needs the site folder itself or only the files inside it. That choice determines whether you preserve the correct structure or accidentally add an extra directory level. If the document root is /public_html and your local folder is named mysite, dragging mysite across creates /public_html/mysite. If the homepage must be /public_html/index.html, open mysite locally and transfer its contents instead.
Drag-and-drop and right-clicking Upload accomplish the same thing. The significant difference is that right-click Upload sends the selected items to whichever remote directory is currently active (no further prompts). Confirm that the desired remote directory is selected above the right-hand panel.
The queue is not really a separate transfer method. FileZilla fills it automatically when you upload a folder, including all nested directories. Manually adding each file to the queue creates more work and makes omissions more likely. @bytefalcon3221 is right about letting FileZilla recurse through the folder, but uploading the top-level folder is only correct when that folder itself belongs on the server.
Check hidden files too. Site folders often contain .htaccess, environment files, or other dotfiles that are easy to overlook. Make sure FileZilla is not filtering them, and be cautious with environment or credential files because the production server may need different versions. With CloudMounter set aside for the moment, the local and remote paths displayed in FileZilla are the paths that matter here.
If the files already exist remotely, FileZilla will prompt you with options to overwrite, skip, rename, or resume the files. Do not choose an option to overwrite every file before determining the contents of the server. Taking a current backup of the remote directory is recommended before replacing an existing site.
After the transfer, verify the layout from the remote pane itself: locate the expected index file, confirm asset and configuration folders are at the right depth, and check that no second copy of the site directory was nested inside the first. File permissions may need attention afterward, but changing them broadly during the upload is more likely to create a security problem than solve one.
Make the upload in a temp server folder first, not on the live site, so that you can look at the resulting tree before any existing files are overwritten. If permitted by your host, rename the directory into place once you’ve confirmed its contents. This also avoids a situation where a partly uploaded set of files is mixed into the old contents during a long upload.
Drag and drop and right-click upload do the same basic thing. Right-clicking is slightly less confusing, but either way you’re using the remote directory currently in the right-hand pane. Note that the queue is just a place for FileZilla to show what’s been added, and you should have it set to add whole folders’ worth of nested files at once rather than having to add each one to the queue separately.
I would not automatically upload the top-level folder as @bytefalcon3221 suggests. That works for a release arranged like releases/site-name/..., but many hosts expect the contents directly inside the document root. Look inside your local folder first. If it contains index.html or index.php plus folders such as css, images, or assets, those items may be what belongs in the remote web root.
After that, the user should check the Failed transfers tab instead of waiting for the progress bar after the supposed completion. It is possible that the transfer finished right before the last file or a stylesheet or a configuration file that has not been uploaded yet. It is best to keep FileZilla’s transfer type set to Auto unless the given host requires some specific type of connection.
I would not advise using CloudMounter as a primary tool for moving files from one cloud to another. Its main application here is mounting the remote server where the user keeps production releases or pre-production backups. The actual SFTP file transfers should still be carried out by FileZilla due to the tool’s ability to maintain the queue and report failed transfers easily audited by the user.
Dragging the whole folder can faithfully upload things that were never meant to be public, such as .git, local backups, cache folders, or development dependencies. That confused me because “preserve the structure” sounded like “send absolutely everything.” Check the folder first and exclude anything the live site does not need.
After that, I’d follow @capt_owl’s distinction: open the local site folder if its contents belong directly in the server’s web root, select those items, then use either drag-and-drop or right-click Upload. Both create the queue automatically and retain subfolders. Let the queue finish, check the Failed transfers tab, and refresh the remote pane before judging the final layout.
The queue is not a safer third method; FileZilla creates it automatically from whatever you drag or upload. Select the correct remote parent, transfer either the site folder or its contents as @capt_owl described, then watch for filename-case mismatches because a Linux server may treat Logo.png and logo.png as different files even if your local computer does not.
If this is an upgrade to an existing site, be careful with old remote files: FileZilla uploads your selection, but doesn’t remove files that you have deleted from the local copy. Make sure you set the right remote parent and then drag or right-click upload, since it will retain subfolders and queue them up automatically.
Before saving that connection, realize that FileZilla will write down your host’s password in plain text by default. If anyone were to look at the config file on your computer, or in backups of it, they could easily see it. If you’re dealing with a truly valuable server, you’d be wise to either set a master password in the Settings to protect the connection profiles, or just not save the credentials at all. Most people never think about the implications of either dragging the site from the directory tree or clicking ‘quick connect’, and then get bitten a few months later.
On the actual transfer, I’m with @capt_owl and @mike34 that drag and right-click do the same job, so pick whichever you’ll misclick less. The thing I’d flag on top of the overwrite prompt: don’t fully trust FileZilla’s ‘file is up to date, skipping’ decision when it compares by date and size. If your machine and the server disagree on timezone, or your editor rewrote a file without changing its size, you can end up thinking something uploaded when the old copy is still sitting there. When it matters, force the transfer instead of leaning on the comparison.
@mike34 framed CloudMounter as basically a place to park release folders and backups, with FileZilla doing all the real SFTP work. I’d loosen that a bit. Where it actually earns its keep for me is the one-line fix: you need to change a single value in a config or a stylesheet, and spinning up a queue for that is overkill. Mount the server, open the file straight in your editor, save, done. No download-edit-reupload shuffle for a five second change. It’s a bad idea for a full deploy, sure, but for tiny edits the mounted-drive approach is less fiddly than babysitting a transfer.
The bit everyone’s circling but not quite saying plainly: FileZilla only pushes what you point it at, it never cleans up. So an ‘upgrade’ where you deleted files locally leaves the deleted versions live on the server. @kernelcraft touched this. Combine that with the case-sensitivity warning from @logicotter1294 and you get the classic mess where an old Logo.png and a new logo.png both exist and the site loads the wrong one.
My process is always to back up the remote directory first, upload and check the tree inside a temp directory, and then replace it. Yawn. This is the difference between a smooth cutover and having to explain to the host why their homepage is empty.
Do not expect the connection to fail, but rather the dragging itself. The dragging is a trivial matter. In half of the cases of the ‘FileZilla does not work’ queries I see on forums, people try to use passive instead of active mode or vice versa, or their firewall blocks the connection, hence the file list may appear, but no files are transferred. In such cases, you need to check the connection settings, not the host!
Honestly, for someone who just asked whether there’s a button they’re missing, a lot of this thread is jumping straight to production deploy paranoia. Useful paranoia, but not for your first upload. The overwrite prompt, hidden dotfiles, case-sensitivity, none of that bites you until you’re pushing a real site with an existing copy on the server. For a plain ‘get my files up there’ job, the core is exactly what @dragon.react said: left is you, right is the server, move things across, then actually watch the queue finish instead of trusting the progress bar.
Where I do line up with @socket.ml is the skip-if-up-to-date thing. FileZilla comparing by size and timestamp has quietly burned me into thinking a change went live when the stale file was still sitting there. When it matters, force the upload.
On the mounted-drive thing, I keep a server mounted with CloudMounter just for those times when a full transfer queue is kind of ridiculous, like opening a remote file to look at it or just check out what’s in a folder without having to open FileZilla for that. But for actually pushing your site, FileZilla’s the name. One thing nobody’s mentioned is that whatever you do, if you’ve got anything in there already, you should back up the remote directory too. Empty homepage at 2am isn’t a fun way to learn that lesson.