WeTransfer for Photo Delivery: The Real Limits
Fine for sending. Quietly expensive as the place a client is meant to respond.
WeTransfer solves one problem completely: getting a large file to someone who does not want an account. That is a real problem and it is genuinely solved.
The trouble starts when the transfer becomes the delivery — when the link is also where the client is supposed to choose, comment and approve. It cannot hold any of that, and the three costs are worth naming before you find them mid-round.
Cost one: the link expires, and the work does not
Transfer links are temporary by design. That is fine for a handoff and wrong for a deliverable, because the client's need to re-download outlives the link by months.
The pattern is predictable. The gallery goes out, the client downloads it, and four months later somebody at their end needs the ceremony shots for a website refresh. The link is dead. You are now the backup service, digging through an archive for a job you closed and billed last year.
Expiry is not just an inconvenience — it silently converts an unpaid favour into a recurring obligation. Every expired link is a future email you will answer for free.
A permanent URL that stays live costs you nothing to maintain and removes that entire class of request.
The asymmetry is what makes this expensive. Your cost of keeping a URL alive is essentially zero. The client's cost of losing it is a request that lands on you, at a moment you have no context loaded, about a job you finished months ago. You absorb the whole cost of a decision the tool made for you.
Paid tiers extend or remove expiry, which helps. But extending a deadline is not the same as removing one, and a link that dies in a year still dies inside the period a wedding client will want their photographs.
Cost two: there is nowhere to reply
A transfer has no surface for a response. The client's only channel is email, which puts you straight back into prose-to-filename translation — the exact failure that makes a single review link worth having in the first place.
Worse, the reply arrives detached from the images. You are reading “the one with the blue chair” while looking at a folder of filenames, holding both in your head. That is not a small annoyance; it is where a round loses a day.
| What the round needs | WeTransfer | Review link |
|---|---|---|
| Deliver large files | Excellent | Good |
| Collect per-image selects | None | Native |
| Keep notes attached to frames | None | Native |
| Survive past the deadline | Expires | Permanent |
| Record what was approved | None | Timestamped |
The absence also removes something subtler: the ability to see progress without asking. In a review surface you can look and know that eleven of forty frames have been marked. With a transfer you know only whether it was downloaded, which tells you nothing about whether anyone has looked properly.
That gap is why transfers generate chase emails. Not because clients are slower, but because you have no way to distinguish “has not started” from “nearly done”, so the only available action is to ask. Every one of those asks costs you goodwill you would rather spend elsewhere.
Cost three: no record of what was agreed
This one stays invisible until a dispute, and then it is the only thing that matters.
Three months after delivery a client says a frame was never approved for the campaign. With a transfer link, the evidence is somewhere in an email thread, if it exists at all, and reconstructing it means reading backwards through a conversation neither of you wrote for that purpose.
An approval that is a timestamped state on an image answers the question in one look. You are not trying to win an argument — you are trying to not have one, and a clear record is what prevents it.
The same record does quieter work day to day. When a client asks “did we ever sign off on the outdoor set?” — usually a genuine question, not a challenge — being able to answer immediately keeps the exchange to one message. Without it, you both go looking, and a two-minute question becomes an afternoon of archaeology for one of you.
This is the argument for a review surface that has nothing to do with features. It is not that approvals are legally fraught. It is that a decision worth making is worth being able to look up.
Where WeTransfer is still the right answer
Three cases where reaching for anything else is overengineering.
One-off handoffs to someone outside the workflow. A magazine wants three files by end of day. They do not need an account, a gallery, or a relationship with your tooling. Send the transfer.
Sending to a collaborator who will immediately consume the files. A retoucher pulling RAWs onto their own disk gains nothing from a review surface.
When the recipient is technically hostile. Some clients will not create an account for anything. A no-friction download link is the tool that actually gets used, and a tool that gets used beats a better one that does not.
The distinction is simple: use it when the transaction ends at “received”. Reach for something else the moment you need the client to do something with what you sent.
There is a fourth case worth naming: when speed of getting started matters more than anything downstream. A transfer needs no setup, no gallery configuration and no decisions about who can see what. If a client is on the phone asking for files now, that zero-configuration property is genuinely valuable, and the right move is to send the transfer and follow up with a permanent link later.
What makes the difference is whether you treat that as the handoff or the process. Sending a transfer because it is fastest today is fine. Building your approval round on it because it was fastest that once is how the three costs accumulate without anyone deciding to accept them.
What clients actually do with a transfer link
It helps to picture the client's side, because their behaviour explains most of the friction.
They receive an email with a large button. They click it, and a browser tab downloads a zip to a Downloads folder they have not tidied since last year. The zip unpacks into a folder named after the transfer, not after your business or their project. At that moment your work has become forty files with your naming convention, sitting inside a folder called something like wetransfer-9f2a1c, alongside a tax document and a firmware update.
Now ask them to pick their favourites. They open the folder in whatever their operating system defaults to, scroll through at whatever size that viewer chose, and form opinions in a context you did not design and cannot see. If they want to show a colleague, they forward the zip, and a second copy exists.
Every copy that leaves your control is a version that can be reviewed, quoted or published later, with no way for you to update or supersede it. Files replicate; links do not.
None of this is the client being careless. It is the predictable result of handing someone a zip and asking them to make a decision. The reason a review link changes the round is not that it has more features — it is that the images stay in a context you chose, at a size you chose, in one place both of you can point at.
There is a smaller benefit that clients notice more than photographers expect: they do not have to store anything. For a corporate client whose laptop is managed and whose Downloads folder is wiped on a schedule, “it lives at this URL” is genuinely easier than custody of a zip.
A practical split that keeps both
You do not have to choose one tool for everything, and most working setups do not.
- Review on a permanent link. Selects, comments, approval — the part with a deadline and a decision.
- Deliver finals however the client prefers. Once the decision is made and recorded, a transfer is a perfectly good courier for the final files.
- Keep the review link live after delivery. It costs nothing and it is where the client looks first when they need something again — which is the same instinct that would otherwise become an email to you.
When you do send a transfer, put the expiry date in the message body. Clients do not read the small print on the download page, and “this link stops working on the 14th” converts an inevitable future request into a download today.
The split works because it matches each tool to the shape of the job. A transfer is a verb: something happens and then it is over. A gallery is a noun: it exists, and people return to it. Approval is the moment the verb becomes a noun, and putting that moment in the tool built for verbs is what creates all three costs above.
Decide it once, write it into your delivery template, and you never have to make the call under time pressure again. The worst version of this choice is the one made at 11pm on delivery day, when whatever is fastest wins by default and becomes the process by accident.
Frequently asked questions
How long do WeTransfer links last?
Free transfers expire after a set number of days, and paid plans allow longer or indefinite availability. The practical point is that any expiry at all makes a transfer unsuitable as the permanent home of a deliverable, because clients routinely need files again months after a project closes.
Can clients approve photos through WeTransfer?
No. A transfer delivers files and has no mechanism for selection, comments or approval. Any approval happens in a separate channel, usually email, which means the decision is recorded somewhere other than alongside the images it applies to.
Is WeTransfer good enough for wedding photo delivery?
It works for the handoff but not as the gallery. Couples come back to their photographs for years, share them with family, and order prints long after any transfer link has expired. A permanent gallery matches how the files are actually used.
What should I use instead of WeTransfer for client proofing?
Anything that keeps feedback attached to the image and gives the approval a permanent, timestamped state. The specific tool matters less than those two properties. Use a transfer service for the final handoff if your client prefers it, but not for the round where decisions are made.