Answer
How to send video revisions to a client:
stop sending a new link every round.
Send the revision to the address the client already has. Uploading a new cut against the same film keeps the URL, the settings and the history intact, so round four does not arrive as a fifth link nobody can find. The one case where you should stack a version instead is at the bottom of this page, along with what a replacement destroys.
Video hosting for filmmakers · 5 GB free · Paid plans from USD 9/month
Updated September 2026
The short answer
Do not send a new link.
Replace the file behind the link you already sent.
The revision goes to the address the client is already holding. You upload the new cut against the same film, and the link they have in their inbox now plays the new cut. There is nothing to announce, nothing to re-explain, and no second page for anyone to land on by mistake.
1
Link, however many rounds
The id, the URL and the slug do not move when the media changes
0
New addresses to explain
The client is told what changed, never where to go
5 TB
Per file, resumable
An interrupted re-export resumes instead of restarting
3
States a film can be in
Reviewing, changes requested, or approved
The mechanism
Only the media changes,
everything around it stays.
A film here is a record with settings attached to it, and the video file is one of those settings rather than the thing itself. Swapping the file leaves the record alone.
The address
The film keeps its id, its URL and its slug. Every copy of that link in the world, sent or forwarded or pasted into a brief, points at the new cut the moment the upload finishes.
Who can get in
Visibility and password settings survive the swap. A film that was password-protected is still password-protected, with the same password, so the client does not need a second set of instructions.
Where it is embedded
Embed settings survive too. A page that already embeds the film plays the new cut without anyone touching that page, which matters most when the embed is on a site you do not control.
The history
The view count carries forward, and so do the review settings. Round four is still the same film as round one rather than a fresh page starting from zero.
The upload itself is the ordinary one. Files go up to 5 TB each and the transfer is resumable, so a large re-export does not need supervision and a dropped connection costs you a pause rather than the round. The player then streams the exact bytes you uploaded, with no re-encode on the way in or on the way out, so the revision the client watches is the export you just made.
Why it matters in practice
Every extra link is a link
the wrong one gets opened.
The reason to avoid a new URL per revision has nothing to do with tidiness. It is that you do not control where your first link went. The client put it in an email thread. That thread got forwarded to their boss. Somebody pasted it into a calendar invite for the review call, and somebody else saved it in a channel with the brief attached. None of those copies update when you send a new one.
So by round four there are four live addresses in circulation and only one of them is current. The person who was not on the last email opens the oldest link they can find, watches a cut you abandoned three weeks ago, and writes a page of notes about problems you already fixed. You then spend the meeting explaining the link rather than the film, and the notes you have to reconcile were written against a cut that no longer exists.
Replacing the file removes the possibility. There is only ever one address, so every old copy of it is also the current one, and the oldest email in the thread is as correct as the newest.
Both columns describe the same job: getting a new cut in front of the same client. The left column is what happens when each revision becomes its own page, whatever tool you use to make it. The right column is what an upload against an existing film does here, verified in product code on 8 September 2026.
The sequence
Upload the new cut,
then send a sentence, not a link.
Decide replace or version first
Ask one question before you upload: will anyone need to see the previous cut again. If the answer is no, replace the file. If the answer is yes, or you are not sure, add a version instead. This is the only decision on the page that is hard to undo.
Upload the new cut against the same film
Open the film the client already has and put the new export against it rather than creating a new one. Up to 5 TB per file, resumable, so a long transfer can be left alone. When it finishes, the same address plays the new cut.
Tell the client what changed, not where to go
The message is about the edit now: the tightened open, the new grade on the interview, the music swap. The link is the one they already have, and it is worth saying so in the email so nobody goes hunting for a new one.
Close the round before you open the next
Notes carry a timecode and a done flag and group into rounds, so work through the open ones and check them off. A note posted on an approved cut revokes that approval, so an approval that survives to the end of a round is a real one.
The other route
Add a version instead
when the last cut still matters.
Replacing is not the only way to keep one link. A film carries several versions, and stacking a new one keeps the same address while leaving the previous cut in place. The two options serve different situations, and picking the wrong one is the mistake this page is really about.
Replace the file when the old cut is finished with
A typo in a lower third. A frame of black at the tail. A mix that was 2 dB hot. Nobody will ever ask to see the previous file, and keeping it around only invites somebody to open it. Replace it and the link, the settings and the count carry on as if nothing happened.
Add a version when the client should compare
A recut opening. A different music bed. A director's pass against a client's pass. Here the previous cut is evidence, not clutter: the client needs to see what moved, and you need a record of which one they said yes to.
What a version gives you that a replace does not
The earlier cut stays playable. Approval is recorded per version, by name, so the film's state is tied to one specific file. Two versions can be put side by side as a slide wipe or stacked, which is a faster way to settle a disagreement than describing it.
What both give you
The same link. Versions stack behind the address the client already has, exactly as a replacement does, so neither route asks anyone to update a bookmark, a calendar invite or an embed.
The rule of thumb
Replace when the change is a correction. Stack a version when the change is a decision. A correction is something the client would be annoyed to be shown twice; a decision is something they have to be shown twice in order to choose. If you cannot tell which one you are holding, treat it as a decision, because a version you did not need costs you nothing and a replacement you regret cannot be undone.
What a replacement costs
The old cut is destroyed,
and it does not come back.
Read this before you replace anything under review
Uploading a new cut over an existing one deletes the previous file at that address. There is no archived copy sitting behind the link, and nothing on the page will offer you the old cut afterwards. If a client asks in November to see what the September version looked like, a replacement means the answer is no.
The one thing that does survive is outside your control. A client who already downloaded the old file still has it on their machine, and so does anyone they sent it to. A replacement changes what your link serves from now on; it does not reach into anybody’s downloads folder. If a cut is sensitive enough that copies of it are a problem, the answer is access control before the fact, not a replacement after it.
There is a second thing worth checking before you swap a file on a film that is mid-review. Timecoded notes are anchored to a moment in a specific cut, so a note left at 01:14 on the old file still points at 01:14 after the swap, which may now be a different shot entirely. On a small correction that is harmless. On a recut where everything after the first minute has moved, it is confusing enough on its own to be a reason to stack a version instead.
None of that argues against replacement. It argues for deciding once, at the top of the round, rather than discovering it afterwards. The replacement guide covers the mechanics in full, and comparing versions for approval covers the other route. If you are choosing a workflow rather than performing one, the review and approval guide is the place to start.
The answer in three lines
Send a new cut,
not a new address.
Put the revision behind the link the client already has. Replacing the file keeps the id, the URL, the slug, the visibility and password settings, the embed settings, the review settings and the view count, and changes only the media, so every old email and every existing embed quietly becomes current. Stack a version instead whenever the previous cut still needs to be watched, compared or approved on its own terms. And remember that a replacement is final: the old file at that address is gone, even though the copy your client downloaded last week is not.
Questions
Frequently asked
Should I send a new link for each revision?
No. Send the revision to the link the client already has. A new URL for every round means the client has to notice which of your five emails is current, and the odds of someone opening round two during round four go up with every link you add. Uploading a new cut against the same film keeps the address exactly as it was.
What actually survives when I upload a new cut over an old one?
The film's id, its URL and slug, its visibility and password settings, its embed settings, its review settings and its view count. Only the media changes. Everything you set up when you first sent the link is still set up afterwards, which is the whole point of doing it this way.
Does replacing the file delete the old cut?
Yes. The previous file at that address is gone once the new one is in place, and this page is not going to soften that. If there is any chance the client will want to see the previous cut again, or compare it against the new one, add a version instead of replacing. A client who already downloaded the old file still has their copy; what disappears is the copy at your link.
When should I add a version instead of replacing?
Whenever the previous cut still matters. A version keeps the earlier file playable, records approval against one specific cut by name, and lets the two be compared side by side as a slide wipe or stacked. Use a version for a real revision round, and a replacement for a fix that nobody needs to see twice.
What happens to embeds and existing emails?
They keep working and they show the new cut. The embed settings survive a replacement, so a page you embedded the film into months ago plays the current version without anyone editing that page. The same is true of the link sitting in an old email thread, a calendar invite or a forward to someone's boss.
How large can the re-export be?
Up to 5 TB per file, and the upload is resumable, so an interrupted transfer picks up rather than starting over. A long re-export does not have to be babysat, and a dropped connection does not cost you the round.
Does an approved cut stay approved after I change it?
Approval is recorded against a specific version, by name, and the film sits in one of three states: reviewing, changes requested, or approved. Posting a new note on an approved cut revokes that approval, which is deliberate. An approval that survives new feedback is not a record of anything.
One address, however many rounds it takes
Send a client one link, put every revision behind it, and keep the notes attached to the cut they were written against. The review room is on every plan, including the free one.