What is the best alternative to FTP?

It depends what you were using FTP for. For handing finished work to a client, a transfer link with an expiry and a download receipt. For an ongoing shared workspace, a cloud drive. For automated server-to-server movement, SFTP or an object store with API access. FTP was doing all three jobs badly, which is why no single replacement covers it.

Is FTP still secure in 2026?

Plain FTP sends credentials and file contents in the clear, which has been unacceptable for years. SFTP and FTPS fix the encryption. Neither fixes the real problem with FTP for client work, which is that access is a standing username and password rather than a link you can expire or withdraw.

Why do agencies still use FTP?

Because it works and it was set up once, years ago, by someone who may have left. It has no per-transfer cost, no size limits and no vendor. The costs are hidden instead: client confusion, support time, credentials that outlive projects, and no record of who took what.

What should I give a client instead of FTP credentials?

A link. One that opens in a browser with no software to install, expires on a date you chose, and tells you when it was collected. If the client genuinely needs ongoing access to a working area, use a shared folder in a tool they already have rather than a server login they will need talking through.

Is SFTP good enough for client deliveries?

It is fine for the transfer itself and wrong for the relationship. You are still asking a client to use a file-transfer client, keep a credential, and navigate a directory tree. That is a technical handover, not a delivery, and it is a strange last impression to leave at the end of a project you were paid well for.

The FTP Alternative for Agencies in 2026

FTP still moves files fine. What it does not do is anything a client-facing business needs — expiry, receipts, revoking access, or looking professional.

There is a particular kind of email that still goes out from agencies in 2026:

Files are on our FTP. Host is ftp.ouragency.co.uk, username is client_acme, password is in the previous email. Let me know if you have any trouble.

They will have trouble.

FTP is not broken. It moves bytes reliably and it has no per-gigabyte bill attached, which is why it survives. The problem is that it was designed to move files between machines, and somewhere along the way agencies started using it to hand finished work to human beings.

What it actually costs you

The client cannot open it. Modern browsers dropped FTP support years ago, so “just paste it into Chrome” no longer works. Your client now needs a file transfer client, and someone at your end needs to explain what one is. That is a support call, at the end of a project, about your own delivery process.

Access has no end date. FTP credentials are standing access, not a link. The account you created for a client in 2022 works today unless somebody deliberately deleted it. Nobody deliberately deletes it. Somewhere on your server there are logins belonging to businesses you no longer work with, pointing at directories nobody has audited in years.

You have no idea what happened. Did they download it? Which version? When? Unless you go and read the server logs, and you will not, the answer is a shrug. Every delivery ends with the same email: did you get that?

One directory, all the versions. FTP has no concept of a delivery. It has a folder, and folders accumulate. final, final_v2, FINAL_USE_THIS, and a client who downloads whichever one sorts first.

And it looks like 2004. This is the one people wave away, and it is the one that costs the most. Everything else in your business is considered — the deck, the presentation, the invoice. Then the actual handover is a hostname and a password in an email. It is the last thing the client experiences, and it says the opposite of everything the pitch said.

What to replace it with depends on what you were using it for

FTP was quietly doing three unrelated jobs. Replacing it means splitting them up.

Job 1: handing finished work to a client

This is most of it, and it is the easiest to fix. Use a transfer link.

The client clicks and gets their files. No software, no credentials, no directory tree, no instructions. And on the sending side you get the things FTP never offered: an expiry date, a receipt when it is collected, the ability to revoke a mis-send, and a page that carries your branding rather than a server prompt.

Job 2: an ongoing shared working area

If both sides are adding files over weeks, that is not a delivery, it is a workspace. Use a shared folder in something the client already has — Dropbox, Drive, SharePoint. The point is that it is ongoing and mutual, which is the one case where standing access is the correct model.

Be deliberate about the distinction, though. A shared folder used as a delivery mechanism is just FTP with a nicer icon: permanent access to a live directory, granted once, reviewed never.

Job 3: machines talking to machines

Deploying to a server, dropping nightly exports somewhere, a feed a partner picks up on a schedule. This is what FTP was actually built for, and here you do not need a human-facing product at all — you need SFTP or an object store with API access and keys you can rotate.

Do not let this job justify keeping FTP for the other two. It is a fifth of the usage and it is the only fifth that works.

The migration is smaller than it looks

Most of the fear here is about the unknown scale of it. In practice:

Stop creating new client FTP accounts today. New deliveries go out as links from now on. This alone stops the pile growing.
List the existing accounts. It will be a longer list than you expect and most of them will be dormant.
Disable anything not touched in six months. Not delete — disable. If someone shouts, you will know within a fortnight, and nobody ever does.
Keep the machine-to-machine paths, move them to SFTP with keys if they are not there already.
Retire the human-facing side entirely, once nothing has used it for a quarter.

The whole thing is an afternoon plus a waiting period. The reason it never happens is not difficulty, it is that it is nobody’s job — which is also why the credentials are still live.

What good looks like

A delivery, in 2026, should be: a link, on your own domain, that opens in a browser with nothing to install. A page carrying your client’s brand. A password when the contents warrant one. An expiry you chose, so the door closes on its own. A receipt telling you it was collected, and by whom. And a revoke button for the day you send the wrong cut, because you will.

That is the list Transfers was built against — 10 GB per send on Agency, 25 GB on Agency Pro, expiry between one and fourteen days, download caps, and the client’s branding inherited from the work you already do for them. It is coming soon on the Living Page Agency plans, included rather than sold separately.

FTP will keep working after you stop using it for this. That was never the argument.

I’m Richard, and I build Living Page — client-facing delivery for agencies. See how Transfers works, or see the agency plans.