Speeding up FileZilla on an older Mac

A transfer that used to finish over lunch now runs into the afternoon. The connection is the same, the server is the same, the files are the same size. The obvious suspect is the Mac, and on an older machine that is a comfortable conclusion, because it requires nothing to be done.

It is also wrong more often than not. Four causes account for nearly every case of this application transferring slowly, and three of them are free to fix in under ten minutes. Only one of the four has anything to do with the age of the hardware, and even that one usually turns out to be a packaging decision rather than a hardware limit.

Measure before changing anything

Adjusting settings without a baseline produces the impression of improvement and no evidence of it. Two minutes of measurement first.

Take a single large file, ideally a few hundred megabytes, and transfer it in one direction while watching the rate in the queue. Then take a folder of several hundred small files totalling roughly the same size and do the same. The gap between those two numbers is the diagnosis.

If the single large file moves at a reasonable fraction of the line rate and the folder of small files crawls, nothing is wrong with throughput. The cost is per file rather than per byte, and no setting will remove it. If both are slow by the same proportion, something is capping the connection, and the next three sections cover what.

The display itself can be adjusted, since the transfer speed readout has a configuration of its own in the settings. Worth setting to something readable before starting, because a rate shown in the wrong unit has sent plenty of people looking for a problem that was not there.

The binary is the first thing to check

This is the largest free win available on any Apple Silicon Mac, and almost nothing announces it.

Open the macOS download page and the heading reads that it serves the Intel build. The offered file is the x86 archive, requiring macOS 10.13.2 or newer. A native build is published in exactly the same release, but it appears only after following the link to the additional download options, listed as a separate platform entry:

FileZilla_3.71.1_macos-arm64.app.tar.bz2 Source: filezilla-project.org

Nothing in the update path switches architecture. An installation carried forward from an Intel Mac, or downloaded from the default button on an Apple Silicon machine, stays translated through every subsequent update, indefinitely.

This matters more here than in most applications, because both secure protocols do work per byte. FTP over SSL/TLS and SSH File Transfer Protocol both encrypt everything that moves, so the transfer rate is partly bounded by how fast the machine can process the stream. A translated binary pays a tax on exactly that work.

The check takes ten seconds. Open the Activity Monitor, add the Kind column, and read what it says next to the process. Replacing the application is a drag and drop, and site definitions are untouched by it. A surprising share of complaints that read as an old Mac struggling end at this step.

The speed limit nobody remembers setting

The second free fix is a feature working exactly as designed, in a state nobody intended.

Speed limits are part of the free client, not an upgrade. The configuration is documented plainly:

Select Transfers from the menu on the left. Tick the Enable speed limits checkbox. Enter a Download limit and Upload limit. Source: filezillapro.com

Reached through Edit, then Settings, then Transfers. There is also a button in the status bar that switches limits on and off without opening anything, which is the source of the trouble. A limit entered once on a hotel connection, a tethered phone or a shared office line stays entered, and the status bar toggle is easy to leave in the wrong position for months. Every transfer afterwards obeys it silently.

Anyone whose transfers all cap at the same suspiciously round number should look here before anywhere else. A cap that is identical on every server, on every network, at every time of day, is not a network problem.

The setting that no longer exists

The third item is not a fix but a warning, and it saves an evening.

For years the standard advice for underperforming uploads on a Mac was to adjust the send buffer by hand in the settings. That advice is now wrong, because the option was deliberately removed:

*nix, macOS: Remove custom send buffer option, rely on operating system auto-tuning Source: filezilla-project.org

That change landed in the 3.70 series, in a release candidate dated March 2026. Buffer sizing now belongs to the operating system, which tunes it automatically.

Forum threads recommending the old setting are still the top results for this problem, and they predate the current builds. Searching the settings for something that has been deleted on purpose is a common way to spend an hour and conclude the application is broken. It is not there, and nothing needs to replace it.

Why many small files are slow

The fourth cause is structural, and understanding it prevents a pointless search for a setting.

The File Transfer Protocol uses two connections rather than one. The official network documentation states the mechanism directly:

What distinguishes FTP from most other protocols is the use of secondary connections for file transfers. Source: filezillapro.com

The control connection carries commands and replies. Every file and every directory listing requires a separate data connection to be established for it, then torn down. On a folder of several thousand small files, the round trips to set up and close those connections dominate the time, and the actual bytes are almost incidental.

This is why a folder of ten thousand icons takes longer than a single video file ten times its size. No speed setting touches it, because nothing is being throttled. The practical answers are to archive the folder into a single file, transfer that, and unpack it on the server, or to use a protocol that does not work this way. Where the destination is a web host with shell access, the first option turns an hour into two minutes.

Two settings for large downloads

Large single files have their own two settings, both documented and both off by default.

Pre-allocation addresses fragmentation on the receiving disk. The official guidance covers when to use it: for large downloads showing fragmentation issues, the client can find contiguous space for each file and create a placeholder to hold it. The switch is under Edit, then Settings, then Transfers, labelled to preallocate space before downloading. On a mechanical drive or a nearly full disk this is worth turning on. On a roomy solid state drive it makes little difference.

The second one matters far more on a Mac and is easy to miss because it lives under a different heading. Idle sleep will interrupt a long transfer, and there is a setting specifically to prevent it:

Tick the Prevent system from entering idle sleep during transfers and other operations checkbox. Source: filezillapro.com

It sits under Interface in the settings, not under Transfers, which is why almost nobody finds it. Anyone who has started an overnight upload and returned to a stalled queue in the morning has been describing this as slowness. It is not slowness, it is a machine that went to sleep, and one checkbox ends it.

The transfer type setting

One smaller lever sits next to those two. The client offers a choice of transfer type, ASCII or binary, with an automatic mode that decides per file from a list of extensions. Binary copies the file byte for byte. ASCII processes it on the way through, converting line endings for the destination system, which is useful for scripts and wasted work on anything else.

The automatic mode is driven by that extension list, and release 3.69.1 in April 2025 fixed the initial loading of those extensions, so a build older than that could be applying the wrong type. Two consequences follow. Large binary files pushed through ASCII processing take longer than they need to, and, more seriously, they arrive altered. Anyone transferring archives, images or database dumps should confirm the type is binary rather than trusting the automatic choice on an older build.

Passive mode, active mode and the router

One more cause is worth separating because it produces stalls rather than a steady low rate.

Passive mode is the recommended default. In it, the client asks the server where to connect and then opens the data connection outward, which means only outgoing connections need to be permitted on the client side. That suits almost every home and office network, since a NAT router allows outgoing connections without configuration. Active mode reverses the direction, and then the router in front of the Mac has to accept an incoming connection, which it usually does not.

The symptom of getting this wrong is not a slow transfer. It is a transfer that starts, transfers nothing, and eventually times out, often after a directory listing that never arrives. If that is the pattern, switching the site between the two modes and retrying is the correct move, and the release notes show the client already retries automatically from a different source port when one common passive mode failure occurs.

What the older Mac genuinely contributes

After all of the above, some hardware contribution remains, and it is worth being honest about its size.

The minimum supported system is macOS 10.13.2. A machine old enough to be near that floor is old enough that its disk, not its processor, is likely the constraint on writing thousands of files. Local antivirus or backup software scanning each arriving file adds a real per file cost on top of the per file protocol cost described above, and that compounds precisely on the small file case that was already the slowest.

None of that is addressed by a different transfer client, which is the useful conclusion. Measure the two cases, fix the binary, clear the forgotten limit, turn off idle sleep, and archive small file sets before sending them. What remains after those five steps is the actual ceiling, and it is usually higher than expected.

Where the remaining friction turns out to be the constant movement between a Finder window, a transfer window and a terminal to check what is really on disk, that is a separate problem with a separate answer. The features page covers what folding the shell into the same window removes from the round trip, and the comparison page sets that class of tool against the transfer clients.

What to change first

Check the Kind column in the Activity Monitor and replace the binary if it says Intel, because that is free and explains the largest share of these reports. Then open the settings and confirm that speed limits are off and that idle sleep prevention is on. If small files are still slow after that, archive them before transferring rather than looking for a setting, and if a whole workflow still feels like three windows rather than one, Atriens is built for the local side of that.