I installed FileZilla and connected to my server fine, but now I’m just staring at two panels full of folders and I have no idea how to actually move a file from my computer to the server. Is it drag and drop, is there a button, what am I missing? Total beginner here.
Once you’re connected, it’s pretty simple actually. The left panel is your computer, the right panel is the server, that’s the whole client-server setup right there. To upload, just find your file in the left panel, then either drag it over to the right panel, or right click it and hit Upload. To download something from the server to your computer, same thing just backwards, drag from right to left or right click and choose Download.
If you’re moving a whole folder, dragging the folder itself works fine too, it takes everything inside it. There’s also a queue at the bottom of the window that shows you what’s transferring and how far along it is, useful for bigger batches of files.
Some threads on this if you want more detail:
If you ever get tired of the two panel drag and drop thing, CloudMounter takes a different approach. It mounts your FTP or SFTP server as a regular drive on your Mac, so you just move files in Finder like you would with any local folder, no separate app window needed. It also does the same for cloud storage like Google Drive or Dropbox in one place.
Don’t re-drag the entire folder just because the “Failed transfers” count increased, since that can create overwrite prompts or duplicate work. Open the Failed transfers tab, check the error message, then right-click and requeue only those files. Dragging the folder is fine, but verify the remote file count afterward and use SFTP rather than plain FTP if your server supports it.
Don’t keep retrying the whole folder until the numbers happen to look right. A completed queue only tells you FileZilla has stopped working through the jobs. It does not prove every file reached the correct directory intact.
Dragging the folder is a normal way to upload it. Once the queue finishes, check the three tabs at the bottom:
- Queued files should be empty.
- Successful transfers should contain the completed uploads.
- Failed transfers should show anything that needs attention.
@codeminer9255 is right about requeuing only the failures, but first read the log message. A second attempt will not fix a permissions error, a storage quota, an invalid filename, or a server that keeps closing connections. If several files fail with the same message, deal with that cause before requeuing them again.
I would leave the transfer type set to Auto rather than manually choosing ASCII or binary. FileZilla can handle ordinary images and text files appropriately. Changing that setting without a specific reason is an easy way to introduce another variable.
Afterward, compare the local and remote folders by file size, not only by file count. Counts can be misleading if a folder contains hidden files or if something was uploaded into the wrong remote directory. For a small batch like 39 files, a quick size comparison is usually enough. If any remote image is zero bytes or noticeably smaller than its local copy, upload that file again.
SFTP is preferable when the host supports it, but switching protocols will not correct server permissions or a full account. The practical routine is: upload once, let the queue finish, inspect failures, fix the reported cause, requeue only those entries, then verify the destination.
The numbers in the bottom tabs may not belong only to the folder you just uploaded. FileZilla can retain successful and failed entries from earlier activity in the same session, so clear those tabs before a test transfer or check the timestamps and filenames rather than treating the totals as a checksum.
After the queue stops, refresh the remote listing before counting anything. The server directory view can be stale, especially after reconnects or a larger batch. Press F5, open the destination folder again, and confirm that the expected files are actually there. That avoids uploading everything twice because the right pane had not updated yet.
If the failures report dropped connections or timeouts rather than permissions or quota problems, reduce the number of simultaneous transfers in FileZilla’s transfer settings. Some inexpensive hosting accounts do not handle several parallel uploads reliably. Using one or two connections is slower, but often finishes with fewer retries.
For 39 files, dragging the folder is perfectly reasonable. Start with an empty transfer history, upload once, refresh the remote directory, and requeue only genuine failures. If the same files fail again, stop retrying and read the server response because the transfer method probably is not the problem.
Make sure the server needs the folder itself, rather than only the files inside it. Dragging “test-folder” onto the remote pane normally creates a remote “test-folder” directory. If those images belong directly in public_html, www, or another application folder, that extra directory level can make the upload look broken even when every transfer succeeded.
Before retrying anything, expand the remote directory tree and confirm exactly where the files landed. This matters with websites because uploading to the account’s home directory is not necessarily the same as uploading to the site’s document root. A perfect transfer to the wrong location still will not appear on the site.
The advice about reading the Failed transfers messages is sound. I would requeue only genuine failures, then refresh the remote pane and inspect a couple of uploaded images from the server. For future uploads, FileZilla’s synchronized browsing can reduce wrong-folder mistakes, but use it cautiously since changing directories on one side changes the corresponding location on the other.
Do not delete or move the local folder after FileZilla reports success. An upload is not a backup, and a completed queue does not protect you from choosing the wrong remote path or overwriting an existing file.
For this batch, upload the folder once, fix only entries listed as failed, then open a few remote images through the site or hosting file manager. Keep the original folder unchanged until you know the files work where they were intended to go.
Turn on FileZilla’s directory comparison instead of eyeballing sizes by hand. There’s a toolbar button for it, or View then Directory Comparison, and you can set it to compare by size and by modification time. Once both panes point at the same folder, matching files stay plain and anything different gets highlighted. For 39 files that beats manually reading a size column, and it catches the exact thing @crystalserver3286 warned about, a file that transferred but landed smaller than the local copy.
The point @data_nick43 made about the extra folder level is the one I’d worry about most here, more than protocol or parallel connections. Dragging test-folder makes a remote test-folder, and if your web root expects the images loose inside public_html, the transfer log will say success while nothing shows up on the site. Comparison browsing helps here too, because if the panes are lined up and half the files are missing, you know instantly they went one directory too deep.
Small thing everyone skipped: check whether FileZilla is preserving timestamps. By default it usually doesn’t over SFTP unless you enable it, so a size-and-date comparison can flag files as different when only the date differs and the bytes are fine. Not a failure, just a false alarm that’ll make you requeue things you don’t need to.
The CloudMounter suggestion earlier makes sense if you’re the type who hates keeping a second window open, since mounting the server as a drive lets Finder do the copying. I’d just be honest that it hides the transfer detail you actually want during a troubleshooting session. When a folder is misbehaving like yours is, seeing the queue and the failed tab is the whole point, so I’d sort out this upload in FileZilla first and save the mounted-drive approach for routine stuff once you trust the connection.
If the failures come back with a real server message, stop retrying and paste it here. Dropped connections, permission errors, and quota problems all look the same in the fail count but need completely different fixes.
Don’t drag anything until the right-hand pane shows the exact server folder you want. Then drag the file from left to right; FileZilla copies it to the server, so the original stays on your computer.
Honestly, this thread has turned a five second task into a forensics investigation, and the person asking hasn’t even done their first upload yet. Drag from the left panel to the right, or right click and hit Upload. That’s it. Everything after that is troubleshooting for when something breaks, and nothing has broken yet.
That said, the one bit of paranoia worth keeping is what @data_nick43 raised. Watch where the files actually land. When you drag a folder, FileZilla makes that folder on the server, so if your images need to sit loose inside public_html and instead you get public_html/myfolder/image.jpg, everything reports success and the site shows nothing. That trips up more beginners than failed transfers ever do. So before you drag, click into the exact remote folder you want first.
The size comparison and connection tuning stuff is real advice but it’s for later, once you actually hit a problem. Don’t go changing parallel connection counts on your first go. As for CloudMounter, I get why it came up, mounting the server as a drive so Finder does the copying is genuinely nicer for routine stuff. But while you’re still learning where files go, the two panel view is doing you a favor by making the source and destination obvious. Get comfortable with that first, then hide it behind a drive later if you want.
Use your hosting control panel’s File Manager instead of FileZilla. Open cPanel, Plesk, or your host dashboard. Select public_html or the site’s document root. Click Upload, then choose your files.
Upload two test images first. Refresh the website and confirm both load. Then upload the remaining files. Keep your local folder untill everything works. This browser method shows the destination path clearly and avoids confusing dual panels. If you upload a ZIP file, extract it on the server to save time, but check for an extra folder level afterward.