Stop Uploading the Wrong Folder: FileZilla's Synchronized Browsing and Directory Comparison

If you've ever deployed by dragging files into FileZilla, you've probably had the moment: you upload config.php, reload the site, and nothing changes — because you were in /public_html/old-backup/ on the remote pane instead of /public_html/. Manual FTP workflows fail in boring, predictable ways: wrong directory, missed file, stale copy left behind.

Two built-in FileZilla features fix most of this without any scripting: synchronized browsing and directory comparison. Together they turn "drag and hope" into "navigate once, see exactly what's different, upload only that."

First, pick the right protocol

Before the workflow, a quick correction that trips people up: FTP and SFTP are unrelated protocols, despite the names. Plain FTP sends your credentials in cleartext and needs extra firewall ports. SFTP runs over SSH (port 22), authenticates with keys, and is what nearly every modern server already exposes. Unless you're connecting to legacy hosting that only offers FTPS (FTP over TLS), choose SFTP.

In FileZilla's Site Manager (Ctrl+S on Windows/Linux, Cmd+S on macOS), create a new site and set:

• Protocol: SFTP – SSH File Transfer Protocol
• Host / Port: your server, port 22
• Logon Type: Key file, pointing at your private key (e.g., ~/.ssh/id_ed25519)

Key-based auth also sidesteps a real FileZilla weakness: saved site passwords are stored in recoverable form unless you set a master password in settings. On a shared machine, prefer keys or enable the master password.

Synchronized browsing: one navigation, two panes

Enable it via View → Synchronized Browsing (or the toolbar icon). From then on, when you double-click into assets/css/ in the local pane, FileZilla automatically changes the remote pane into the matching assets/css/ directory — and vice versa.

This sounds minor, but it eliminates the most common deployment mistake: the two panes drifting apart. The catch is that it assumes your local and remote directory structures actually mirror each other. If your local project root contains build tooling (node_modules/, .git/) that doesn't exist on the server, set the correct starting points first: right-click each pane's directory and use the Site Manager's Advanced tab to define a default local directory and default remote directory. Synchronized browsing then works relative to those roots.

Directory comparison: a visual diff before you deploy

Enable View → Directory Comparison and FileZilla color-codes the file lists:

• Yellow – file exists on only one side
• Green – file exists on both, but one is newer
• Red – sizes differ
• No highlight – files match

You can toggle the comparison basis between modification time and file size (View → Directory Comparison submenu). Timestamp mode is fast but can mislead you: if your laptop and the server disagree on timezones or clock skew, files show as "different" when they're identical. Size-based comparison is slower but more trustworthy — and for text files of identical size it can still miss content changes, so treat it as a strong hint, not a hash check.

A worked deploy

Here's the full loop for a small site update:

1. Connect to your SFTP site; both panes land on the default directories you configured.
2. Turn on synchronized browsing and directory comparison.
3. Edit your files locally as usual.
4. Navigate to the changed folder once — the remote pane follows.
5. The changed files light up in green or red. Select just those, right-click, Upload.
6. For a larger change set, add everything to the transfer queue instead (Add files to queue), then process the queue with Ctrl+P. Failed transfers stay in the queue and can be re-queued rather than hunted down again.

Verification is built into the same view: after the upload completes, the highlights should clear. If a file stays highlighted, the transfer didn't take — check the Failed transfers tab at the bottom before assuming the deploy is done.

Trade-offs worth knowing

This workflow is deliberately manual, and that's both its strength and its limit. It gives you a human checkpoint before anything touches production, but it doesn't scale: no atomic deploys, no rollback, no automation. If you're deploying more than occasionally, a pipeline (rsync over SSH, or a CI job) is the better tool — FileZilla's model is "careful human at the wheel."

Two smaller knobs matter on shared connections: under Edit → Settings → Transfers you can cap concurrent transfers and set speed limits, so a big upload doesn't saturate your uplink and freeze your video call. And when downloading the client, get it from the official site and read the installer screens — some download sources have historically bundled optional offers.

The takeaway

Pick SFTP with key auth, set matching default directories, and leave synchronized browsing plus directory comparison on permanently. You'll navigate once, see a color-coded diff of exactly what changed, and upload only that. It's a five-minute setup that removes an entire category of self-inflicted deployment errors.